Some cvs2bzr thoughts

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?


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?


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?


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.

Max.

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

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

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

iEYEARECAAYFAkrLy4sACgkQfFNSmcDyxYDCWACfTw2sWPG5dBL5vRq73K0bOwhL
LsMAoM2wKxAASapaOgCkzGi6b18WYLV1
=cQzy
-----END PGP SIGNATURE-----