Re: Some cvs2bzr thoughts

[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.

> 2) Having done this, you end up with lots and lots of branches. Which is
> better than the tortuous history of every tag fixup in one branch, but
> poses a problem that bzr tags are local to a branch. Thus, its
> impossible to see these tags when browsing the trunk. I believe the
> proper way to solve this for a bzr conversion is to merge the tag fixup
> branch back into its primary source branch immediately after making the
> last commit on the fixup branch. I'll need to pore of the source a bit
> more to figure out how to make this happen, but does the concept sound sane?

I don't know enough about bzr to offer an opinion.

> 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.

> 4) The workflows of bzr push towards a situation where every branch is
> either merged, or abandoned and drifts into obscurity. That is to say,
> because there's no concept of stashing a branch in the main repository,
> ignoring it, but having it obviously there for people to inspect, as
> there is in the git and hg worlds. Moreso than these, then, an ideal
> cvs2bzr conversion will inject synthetic merges in the DVCS when a
> branch has been merged back to trunk in CVS. Since there's no automated
> way to distinguish this, it'll have to rely on human hinting. Which
> leads me to my point: I think cvs2dvcs needs eventually to grow a
> feature where additional merge ancestry can be supplied for grafting
> into place. I've no idea how this should work just yet, I'm just
> throwing the idea out for pondering.

git lets you write a (nonversioned) .git/info/grafts file to arbitrarily
change ancestry info in an existing repository, and git-filter-branch
uses that info to change the ancestry as it rewrites a repository.  So
for git, this kind of human-driven rewriting can be done
post-conversion.  But even for git, it would be nice if cvs2git would
supply output that helps the human decide what grafts to create.

But that doesn't help the other DVCSs, so an in-conversion mechanism
would be even better (i.e., kill two or three birds with one stone).

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!)

(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)

And any of these possibilities could be modified to permit user input.
We might consider something like the --write-symbol-info/--symbol-hints
mechanism that allows the user to edit a file between passes to express
his wishes.

Michael

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

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