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