On Fri, 2008-04-04 at 11:52 +0200, Michael Haggerty wrote: > 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. > More or less, yes. It gets worse if a user does 'cvs update' in a directory, or on an individual file. > > 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 'my framing of the problem.' It's 'the design goal of cvsps is not compatible with the desire to use the output of cvsps to create a git repository.' See the difference? > > 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. > Yes. That's what cvs2git was designed for. Look at the name. In order to create the 'fixup' branch, you have to make some out of operations, which is fine if that's what your design goal is. The design goal of cvsps was always simply to show who did what and in what chronological order. However, just with that, it's impossible to use for the purpose it is currently being used for. The 'fixup branch' sounds like a really great idea and an elegant solution. > > 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. > I'm quite happy that there are other tools, and even more happy if they already fix every bug that git-cvsimport has. I was simply addressing the bug from the standpoint of: this issue can be fixed without compromising what cvsps wants to be as a tool. The place where the fixup branch logic needs to be is in git-cvsimport, not in cvsps. Better yet, get rid of git-cvsimport and replace it with cvs2git if it works better. However, if possible, I'd like to fix problems with the cvsps/git-cvsimport if possible, unless someone can tell me for sure that it's obsolete and noone uses it. Thanks, David -- 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
