Re: Some cvs2bzr thoughts

On Tue, Oct 6, 2009 at 6:58 PM, Max Bowsher <[email protected]> wrote:
> I've just been trying out cvs2bzr - some thoughts:
>
[...]
>
> 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?

cvs2hg had exactly the same problem.  (Mercurial really doesn't like
repos with many many heads.)  Oddly enough, I came up with and
implemented the same solution as you propose.  My code has not yet
been merged into the cvs2svn trunk, so you might want to poke around
my "branch" of cvs2svn a bit:

  http://vc.gerg.ca/hg/cvs2svn/

In particular, an explanation of how I handled fixups is in

  http://vc.gerg.ca/hg/cvs2svn/raw-file/tip/README.cvs2hg

and the code (class HgOutputOption) is in

  http://vc.gerg.ca/hg/cvs2svn/raw-file/tip/cvs2svn_lib/hg_output_option.py

Follow self.pending_fixups to see how it works.

It sure would be nice to avoid duplication.  In particular, my module
dvcs_common.py *has* been accepted upstream, so it would make sense to
factor code common to hg and bzr out to there.

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

Also handled by cvs2hg.  See HgOutputOption.detect_merge().  Not sure
if there's scope to share code, but there is definitely room for a
common interface.  (Imagine someone converting to both hg and bzr for
a head-to-head comparison: would be nice if they only had to implement
detect_merge() once!)

Greg

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

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