[PATCH 0 of 1] convert: better support for CVS branchpoints (issue1447)

Michael Haggerty mhagger at alum.mit.edu
Mon Jun 8 04:25:19 CDT 2009


Henrik Stuart wrote:
> Michael Haggerty wrote:
>> Henrik Stuart wrote:
>>> Unfortunately, the alternative, cvs2svn, does not easily accomodate
>>> CVSNT's extensions that I am fairly interested in.
>> It would be very easy to teach cvs2svn to honor CVS's commitids:
> 
> It's not so much commitid's I'm worried about - it's more things like
> CVSNT's unicode feature (in particular if it hasn't been turned on until
> half-way through a repository, so some revisions are in one codepage and
> others in UTF-8), the -ku keyword option that indicates it's in UTF-16LE
> (as far as I recall), mergepoints for more accurately tracking merges
> between different branches, etc.

What is the "unicode feature"?  Does it tell how metadata such as the
filename and lot messages are encoded, or does it tell how the file's
contents are encoded?  If the latter, why does CVSNT need to know?  (The
only reason I can think of for the VCS to know the content encoding
would be to expand keywords.)

>> The net effect would be that cvs2svn would not allow file revisions with
>> differing commitids to be included in a single changeset.
>>
>> (It would, of course, not guarantee that all revisions with the same
>> commitid *are* included in a single changeset, but that is what you want
>> because there might be other constraints inconsistent with the commitid
>> information.)
> 
> Indeed, for instance an initial import will, with the same commitid, do
> commits on both HEAD and the vendor branch, which will have to be broken
> up with most DVCS', but you probably already knew that.

Yes, cvs2svn has an option to either allow changesets that span multiple
branches (useful for Subversion) or to split them into branchwise
changesets (required for DVCSs).  So this is no problem.

>> The reason that cvs2svn does not officially support CVSNT conversions is
>> that the file formats of CVSNT seem poorly documented and more fluid
>> than those of CVS, and that nobody with CVSNT experience and interest
>> has stepped forward to work on it.  Anyway, converting CVSNT
>> repositories seems usually to work, aside from commitids, mergepoints,
>> and the revision-specific file modes [1].
> 
> Those are exactly the ones I need. :o)

It would be helpful if you would give a short description of these
features as implemented in CVSNT and how you propose that they should
affect a conversion.

>> If you would like to improve cvs2svn in these directions, I would be
>> happy to help you get started.
> 
> I will probably start looking at it soon-ish.

Cool-ish. :-)

Michael


More information about the Mercurial-devel mailing list