Re: Working towards merge of cvs2hg

On Mon, Aug 23, 2010 at 12:14 AM, Michael Haggerty <[email protected]> wrote:
> I have spent some time preparing a merge of your cvs2hg back into the
> cvs2svn upstream.
>
> I think that the best way to merge the two branches is
>
> 1. Work on both sides to make them look as similar as possible, until
> the only remaining differences are in cvs2hg-specific code.
>
> 2. Slop the remaining diff from the cvs2hg branch onto master in one big
> commit or (if somebody is motivated) a short series of logical and neat
> commits split out of the diff.

Seems reasonable.  That was my general approach back when I tried to
do it with a patch queue using MQ.

> To that end, I have made a few commits on top of my import of your
> cvs2hg branch here:
>
> http://repo.or.cz/w/cvs2svn.git/shortlog/refs/heads/cvs2hg
>
> namely
>
> c2a6728 _get_source_groups() already returns a list.
> ef1009d Fix merge of upstream r4998.
> e6f5885 Merge branch 'master' into cvs2hg
> a8893da Fix whitespace errors.

Totally fine.  I trust you to do the right thing, and those changes
are certainly safe and innocuous.

> I have also cherry-picked some more stuff from cvs2hg into master.
>
> 4c23aa3 dvcs_common: Change tuple order in _get_source_groups() return
> value.
> 58587e2 dvcs_common: Change _get_source_groups() return value into a list.
>
> Please let me know if you have any comments.

If doing that makes the final merge smaller and easier, I'm all for it.

> I have one big question: is there a need to preserve a variant of cvs2hg
> that generates hg-fast-import data, in addition to your code that works
> via the Mercurial Python API?  I'm still a little bit nervous that AFAIK
> the Mercurial Python API is not guaranteed to be stable.  This means
> that (1) somebody in the cvs2svn project will need to track changes in
> the Mercurial API and (2) particular versions of cvs2hg will only work
> against a particular range of Mercurial versions.  A hg-fast-import
> version might not be so sexy and might not be able to support as many
> features, but at least it is working against an interface that is
> presumably more stable.

I wouldn't worry about it too much.  Here, I'll make you a deal: if
you pitch in and help merge cvs2hg into the cvs2svn mainline, then I
will commit to keeping it compatible with Mercurial API changes in
future.  Heck, I'll even configure my public BuildBot instance so that
we know within 24 hours of an incompatible change to the Mercurial API
that it breaks cvs2hg.

As for the range-of-versions concern: right now, cvs2hg works with
Mercurial 1.1, 1.2, 1.3, 1.4, 1.5, and 1.6.  Not bad.  I see no reason
to drop support for 1.1.  I haven't tested it with the code that is
going to become 1.7, but breakage is likely and usually not too hard
to accomodate.  As long as cvs2hg keeps up with Mercurial API changes
and does not drop support for old versions, I think it'll be OK.
Another way of looking at it: if you're running the latest Mercurial,
you will probably need the latest cvs2svn -- but that's fine, because
both are easy to run from source, or just an "apt-get" or "yum" or
"pacman" command away from being up-to-date for people who like to run
the latest stuff.  If you're conservative and using an old cvs2svn,
then you are probably also using an old Mercurial.  The big risk is an
OS that packages the latest Mercurial but lags on cvs2svn.  People in
that situation will just have to download a recent cvs2svn tarball,
which is not a big deal.  Not even a C compiler needed, right?

Finally, if hg-fastimport does not support the full gamut of
fastimport syntax as emitted by cvs2git, that is not your problem.
Complain to the maintainer of hg-fastimport (that lazy
good-for-nothing bum) and get him to fix it.  It ought to be possible
to feed cvs2git output into hg-fastimport and get something decent.

Greg

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

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