git-cvsimport gets parents wrong for branches

Hi,

Just by accident I noticed, that git-cvsimport got the parents for branches wrong in one of my projects.

To assist in debugging this, I've made up a testcase script (appended to this mail). It will create a new cvs-repo, put 4 commits in it, and finally run gitk to investigate it.

It should look something like this:

    4 [branch-stable-fixes] commit-on-branch
  3 | [master] [origin] commit-master-after-branch
  |/
  2   [tag-branchpoint] commit-first-edit
  1   commit-base

What it really looks like:

  4   ..
  3   ..
  2   ..
  1   ..

4's parent is 3, not (as it should) 2.

I've tested with 1.4.0 and the current git-cvsimport from 8fced61.

I hope the testcase helps tracking the problem down.

    Elrond

p.s.: The testcase script is not nice. It just does the
      job, nothing more.

Elrond,

you are right, the current git-cvsimport takes a very naive approach to determine where branches open from. It uses cvsps internally, which only reports on the ancestor branch, so we take the latest commit from the ancestor.

Parsecvs probably has a more sophisticated approach, have you tried it?

It is pretty hard to get that one right in any case, as there are cases where the new branch starts from something that is not a commit in the parent (from GIT's perspective). So representing the branching point would mean pointing to non-existing commits as parents.

If the cvs2svn documentation is not lying, it probably has the smartest/correctest implementation. For small-medium repos, you may be able to run cvs2svn and then import with git-svnimport.

cheers,

martin

Hi,

On Tue, 4 Jul 2006, Martin Langhoff wrote:

But it should be easy to introduce a faked commit, which just contains those versions (and takes the newest commit touching any of these file versions as branch point).

Ciao, Dscho

On Tue, Jul 04, 2006 at 10:09:18AM +0200, Johannes Schindelin wrote:

Of couye in theory, (if cvs was used sanely), the base of each branch should be a commit on the parent-branch. But as we all know, cvs allows pathologic cases. (My script doesn't create such a case, it's sanely representable in git without any fake commits.)

So now for the patholigic cases (when they're solved, the main issue is solved too):

Of course, the base version for a branch can be turned into a tree (should be easy: cvsps's first changeset of the branch has the previous revisions of each file). This tree can also be turned into a fake commit... just which parent should our new fake commit have?

My current simple answer is: The commit on the parent branch with the most matching number of files, so that the diff, that the fake commit introduces has the least number of files.

In the non-patholoc case, the fake commit would introduce no diff at all and should be dropped.

Of couse I have no idea, how hard it would be to implement this. And in reality, it would be cvsps's job to do that.

    Elrond

Hi,

On Tue, 4 Jul 2006, Elrond wrote:

That is what I tried to address with the "branch point" thing. Just take the newest commit (in the ancestor line) touching the file versions of that particular tree, or in other words, the oldest commit having at least these file versions.

IMHO it is dumb enough not to branch off of a commit that it does not matter that much what parent this faked commit has.

Ciao, Dscho

On Tue, Jul 04, 2006 at 11:15:47AM +1200, Martin Langhoff wrote:

If there is no fix visible, it probably should be documented, that git-cvsimport isn't the perfect solution, so people aren't surprised.

After finding the current correct git:-url [1] for it, I noticed, that I need libgit for it (I use git from my distribution), so I've postponed this. Of course, you can use my script and try parsecvs yourself.

I'll try that soon.

    Elrond

[1] git://anongit.freedesktop.org/git/users/keithp/parsecvs