CVS conversion: making it look like merges happened

[Greg Ward]

[my original question]
> Right now I'm playing with this technique to create fake merge revisions:
>
[...]
>  bzr merge ../3-6-1
>  bzr revert .
>  bzr commit -m"Fake merge from branch 3-6-1 to 3-7-1."
>
> Repeat, fake merging branch n-1 onto n, up until n=trunk.
[...]
> Is this a completely stupid idea?  Is there a cleaner way to do it?

[Martin responds]
> No, it's not a bad idea at all.  Unless doing it this way was too much
> work it's probably what I'd try first.

It worked fine, both with Bazaar and Mercurial.  Seems like a
reasonably sensible thing to do as a post-conversion step to make
merging fixes work the most natural way -- i.e. fix a bug on branch
1.1 and then just merge all of 1.1 to 1.2 and trunk.

One thing that briefly confused me in Bazaar was the difference
between "bzr revert" and "bzr revert .".  Specifically, "bzr revert"
throws away changes to the working copy *and* the knowledge that there
is a pending merge, while "bzr revert ." only throws away changes to
the working copy.  Subtle, but highly useful.  I didn't see this
distinction mentioned in the docs, though.  (In the case of creating a
fake merge, it's important to use "bzr revert .".)

> I thought there was a bug related to this but I couldn't find one, so
> I filed https://bugs.edge.launchpad.net/bzr/+bug/348227 asking for a
> way to do it in one step.

Seems like overkill to me: this is a one-time-only operation for most
people.  It probably deserves to be documented though: not everyone
has spent months hanging out on the Mercurial list to see how things
are done there before getting around to learning Bazaar.  ;-)

[back to my original post]
> (Mercurial's CVS convertor supports regex detection of CVS merges,
> which I think might work for us in 80% of cases.  I haven't tried it,

I have since tried this feature, and it works reasonably well: you end
with a much richer DAG that more accurately describes what really
happened in your CVS repo.  I'm working on a patch to Mercurial that
should make it a smidge more accurate still.  But of course that
doesn't benefit Bazaar at all...

[Martin again]
> I believe that the fast-import stream can represent merges and we will
> handle them correctly (imbw), so it might be worth either adding that
> feature to the cvs fastexport generator, or doing it yourself as a
> postprocessing step.

...that was my next idea.  I'll probably cobble something hackish
together to postprocess the fast-import stream that I feed to bzr (or
git for that matter, since I'm using it as a performance benchmark for
hg and bzr).  If that works out, I'll see what the cvs2{svn,git,...}
maintainers think.

Greg