David Mansfield wrote: > The main issue with git-cvsimport stems from an unfixable problem. > cvsps's design goal is to show commits in chronological order. Based > solely on this data, it's impossible to always reconstruct a branch > point (or a tag) since a person could have committed files after someone > else's commit, but not done an update then tagged. Just to be more explicit, I think you are talking about a situation like this: 1. Add file1:1.1 and file2:1.1 to repository. 2. User1 modifies file1 and commits file1:1.2. ...some non-negligible amount of time passes... 3. User2 modifies file2 and commits file2:1.2. 4. User2, without updating file1 to revision 1.2, adds a tag. This results in a tag that refers to file1:1.1 and file2:1.2, even though those two revisions never appeared in the repository at the same time. > So some files are from before the 'other' user's commit, and some files > after. What can you do? You can do the only thing that is consistent with the CVS history--create the tag not from a single source revision but from multiple revisions. Unfortunately, git cannot handle this directly, but there is a workaround using a "fixup branch" [1]. cvs2svn/cvs2git [2] creates a "fixup branch", copies file1:1.1 and file2:1.2 onto that branch, then creates the tag from the fixup branch. This ensures that checking the tag out of git gives the same file contents as checking the tag out of CVS. I think that git-cvsimport gets this wrong (!?!) It is your framing of the problem that is leading to the impossibility. CVS's design does *not* require that a tag or branch is created in a single commit, nor that it is created from a single source revision. Trying to impose these artificial constraints means that the resulting git repository is inconsistent with the CVS repository in quite common circumstances. > It's not per se a flaw in cvsps, it always wanted to show commits in > chronological order, but it is a severe limitation in using cvsps to > generate changesets for git. cvs2git always creates commits in chronological order too, but its output is by design always consistent with the CVS record. > By engineering a direct tool (such as parsecvs, I presume) these > obstacles can be overcome by constructing some commits that were never > made by the actual users of the cvs repo in order to get it right. > > I'm not sure exactly how this is done, because I've never looked at > parsecvs. cvs2git's design is documented quite extensively, if you are interested [3]. Parsecvs, AFAIK, uses a similar approach. Michael [1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html [2] http://cvs2svn.tigris.org/cvs2git.html [3] http://cvs2svn.tigris.org/svn/cvs2svn/trunk/doc/design-notes.txt -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
