Re: cvs2git wrongly deletes files when creating branches

Markus Schöpflin wrote:
> [...]
> What I'm seeing is that during the conversion from CVS to Git a file 
> incorrectly gets deleted an then added again later, and in addition a 
> branch is created at the wrong point.
> [...]
> 
> Cvs2git completed the conversion and Git successfully imported the result. 
> But looking at the converted repository, one can see that when creating the 
> branch symbol00000, the file dir008/dir007/dir005/dir004/file001 gets 
> deleted in commit e882abff9d6e2c77e041052f2650bed0feb90e7e and added again 
> in commit 95d899970e0ad4dcb395a2fb2ba8c2cdebe5eba5.
> 
> As can be seen from the CVS revision numbers in the files, the branch 
> symbol should have been created with commit 
> 23334f07c8121131c27f48babc0c792b9d955b90 instead, and the file in question 
> not deleted.

Thanks for the most thorough bug report I can recall every seeing!

Here is some analysis:

symbol00000 is

    file001:1.1.1.1.30.1.2.1.2
    file002:1.2.2

Here are the relevant commits in the two files:

    file001:1.1.1.1.30.1.2.1     2004.03.11 "log 5"
    file001:1.1.1.1.30.1.2.1.2.1 2004.07.19 "log 8"
    ...
    file001:1.1.1.1.30.1.2.1.2.5 2005.05.23 "log 12"
    file001:1.1.1.1.30.1.2.1.2.6 2010.02.19 "log 13"

    file002:1.2                  2005.12.16 "log 1"
    file002:1.2.2.1              2006.11.07 "log 2"

Note: A file can only be added to a symbol *after* its parent has been
added but *before* any commits on that branch.  So it is clear that the
two files were not added to symbol00000 at the same time, because there
was a commit to file001 on the branch *before* the branch's parent 1.2
was even created in file002.

So by my analysis:

1. The symbol00000 branch should initially be created between "log 5"
and "log 8" by copying file001 from the symbol00001 branch.  (That's the
only file on symbol00001 at the time, so there is no diff involved.)

2. Revisions "log 8" through "log 12" should be committed to the
symbol00000 branch.

3. Revision "log 1" should be committed to master.

4. file002 should be copied from master to branch00001.

As far as I can see, this is exactly what the 2.3.0 version of cvs2git
does.  (The strange commit "file file002 was initially added on branch
symbol00004" is misleading because there is no symbol00004; presumably
it was deleted by shrink_test_case.py.)  Aside from the fact that the
2.3.0 output is a bit wordy, I don't see any problem with it.

The trunk version of cvs2git, on the other hand, does indeed seem to
have a problem.  According to a bisection, the problem was added in
revisions r4949 + r4950 by maxb.

Max, would you please look into this?

Another minor issue: I see that trunk is chosen as the preferred parent
of symbol00000.  This is not optimal.  In file002, the parent of
symbol00000 is listed as trunk, where in reality it doesn't have a
parent because the trunk 1.1 revision was a fictitious "dead" revision.
 The problem arises because we don't get rid of these dead revisions
until after the parent statistics have been computed.  If this were done
correctly, then symbol00001 would be the only possible parent found for
symbol00000 (i.e., in file001) and would therefore be chosen as the
preferred parent.

I have appended a slightly simpler test case (e.g., cvs2git is run from
the command line rather than from an options file; the CVS directory
structure is simplified).

Michael

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

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