Re: Some cvs2bzr thoughts

Michael Haggerty wrote:
> [CC to Ian Clatworthy, because I don't think he is subscribed to this
> mailing list.]
> 
> Max Bowsher wrote:
>> I've just been trying out cvs2bzr - some thoughts:
>>
>> 1) The current TAG.FIXUP branch approach inherited from git really
>> really doesn't work for bzr. However, it can be easily fixed by
>> generating a unique name for each tag fixup branch. I propose to derive
>> a BzrOutputOption from GitOutputOption, and delegate the naming of fixup
>> branches to a method that it overrides to supply
>> "tag-fixup.%(tag_name)s". Sound OK?
> 
> Sounds good.

Committed.

>> 3) One of the tags in my CVS repository contained / characters. bzr
>> fast-import didn't like this very much, and created a branch named only
>> the portion after the last /. Perhaps we should be recommending people
>> remap symbols to not contains / characters in the default options files?
>>
>> Come to think of it, I'm not sure what git would do here, but it seems
>> dodgy since git style refs/heads/foo things are /-separated paths.
>> Perhaps we should be banning / in symbol names for fast-import output?
> 
> If you create a git branch with a slash in it, git simply creates the
> branch one level deeper in the directory tree.  (This holds for the
> command-line client and I assume it also holds for git-fast-import.)  So
> there is no need to ban "/" in git branch names.  But it seems perfectly
> reasonable to provide different name-mashing for the different backends.

Hmm. Sounds like I should take this one to the bzr-fastimport folks.



> Arguably *all* of the ancestry information that cvs2x generates for
> branching and tagging files is suspect when migrating to a DVCS, except
> when *all* files on the parent branch are branched or tagged at the same
> time.  This is because in a DVCS, "revision A is an ancestor of revision
> B" implies that all changes that were made leading up to A are also
> contained in B.  But adding a single file to a branch (which currently
> causes cvs2x to generate a merge) implies nothing of the sort.  I wrote
> a bit here about the difference:
> 
> http://softwareswirl.blogspot.com/2009/08/git-mercurial-and-bazaarsimplicity.html
> 
> When should ancestry information be generated by default?  A few
> possible policies would be:
> 
> (1) generate *no* ancestry connection from parent branch to new
> branch/tag (simple to implement!)

Hah!

> (2) generate only "obvious" ancestry information, when each and every
> file on the parent branch is added to a new branch/tag at the same time
> (strictly better than (1) but a little bit of work, and may miss some
> justifiable ancestry info due to issues #54 and #55)
> 
> (3) generate ancestry information only on branch/tag creation (i.e., not
> when files are added later to an existing branch).
> 
> (4) generate ancestry information whenever a file is added to a branch
> (cvs2x's current practice)

I don't think (4) is sensible.

I am in favour of (3), with cvs2x writing a detailed report into the log
message of the branch creation commit, detailing which files were
effectively cherrypicked from other revisions.

Max.

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2405457

To unsubscribe from this discussion, e-mail: [[email protected]].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrPAhgACgkQfFNSmcDyxYB31wCggPFf9D9fd7fUpWU68zp8CKB9
T5gAoMgXUPS2A+qaJ6PQFP2ZFJKeYMRj
=GXaa
-----END PGP SIGNATURE-----