Re: PATCHES: start adding Mercurial backend (HgOutputOption)

Michael Haggerty <[email protected]> Sun, 27 Sep 2009 03:56:25 +0200
Newsgroups gmane.comp.version-control.subversion.cvs2svn.devel
Message-ID <[email protected]>
Greg Ward wrote:
> On Fri, Sep 4, 2009 at 10:08 AM, Greg Ward<[email protected]> wrote:
>> I've finally started assembling a patch queue that adds the Mercurial
>> backend, HgOutputOption.  This is a pretty big patch series, so hang
>> on to your hats.

I've started reviewing your patch series.

I noticed comments in a couple of places that question what "post
commits" are and why you should care about them.  Here is the explanation:

When the user imports a file, CVS creates a vendor branch and creates a
revision 1.1 and a vendor branch revision 1.1.1.1 that is identical to
it.  This reflects the status that the contents of the vendor branch are
also reflected on trunk.  It sets the default branch to point at the
vendor branch.

If the user imports a second version onto the same vendor branch before
he has modified the file on trunk, then CVS creates a vendor branch
revision 1.1.1.2 but *does not modify trunk*.  However, if the user
checks this file out of CVS with no explicit branch specified, then CVS
uses the version on the default branch, which is still 1.1.1.
Therefore, revision 1.1.1.2 *appears* to be on trunk even though it is
not stored on the trunk line of development in the CVS repository.

This situation can be repeated for multiple imports onto the vendor branch.

When the user finally modifies the file on trunk, then CVS creates a
revision 1.2 and removes the default branch.  From then on, checking the
file out of CVS without specifying an explicit branch returns the
contents from the tip of trunk.

Since SVN and git and hg do not have this magical "default branch"
behavior, cvs2svn has to find some other way to make the contents of
revisions 1.1.1.2, etc. show up when trunk is checked out.  It does so
by creating a "post commit" that follows the commit that creates
1.1.1.2.  This post-commit commits the same contents that were in
1.1.1.2 onto trunk.  (Actually, when writing to a DAG-based VCS, one
could consider these post-commits to be merge commits between the vendor
branch and trunk.)

If you completely ignore the post-commits, then your trunk branch
history will be wrong for any files that were ever imported twice (i.e.,
files that have a revision 1.1.1.2).  And for files that have been
imported twice but never modified on trunk, the current trunk version of
the file will also be wrong.

Michael

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

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