Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps

[Michael Haggerty <mhagger@alum.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]

Michael J Gruber wrote:
> [...]
> Right now this really seems to be going in the direction of: Make
> everyone feel uneasy about working with git on cvs repos at all (aka
> guerilla git), because git cvsimport still seems to be "recommended" or
> "the standard", we have all this talk about how bad it is, and no clear
> alternative.
> 
> I wish we had something saying: "If your cvs repo fulfills these
> conditions you can use cvsimport. If not watch out for the following
> (cvsps related) caveats. If you don't need two-way sync you're better of
> with..."

Good idea.  Let me try to summarize the situations I have found that can
result in cvsps/cvsimport giving objectively incorrect output.  I am
only including the most blatant problems that can cause the content
checked out of git to differ from that checked out of CVS.  I have
attached some scripts that illustrate some of the problems that I
haven't yet submitted to the test suite.


Problems known to occur in the conversion of CVS HEAD:

- If any files were ever "cvs import"ed more than once (e.g., import of
more than one vendor release) but not modified locally, then the HEAD
version is incorrect (t9601-cvsimport-vendor-branch.sh).

- If the CVS timestamps on subsequent revisions are out of order (e.g.,
because of clock skew) then file commits can be out of order in git
(e.g. b.txt<1.2> overwritten by b.txt<1.1>).  This is demonstrated by
t9603-cvsimport-time.sh.

- If two files ever had what look like cross-cross commits within
cvsps's 5-minute time window (e.g.,

a.txt<1.1> Log message 1
a.txt<1.2> Log message 2

b.txt<1.1> Log message 2
b.txt<1.2> Log message 1

) then the commits of one file will be out of order in git (e.g.
b.txt<1.2> overwritten by b.txt<1.1>).  I have a test for this that I
haven't yet submitted.


Problems known to occur in the conversion of CVS branches:

Any of the above problems can occur, plus:

- A branch does not appear in the git repository if no commits were made
on the branch (t01.sh)

- All files from the branching point are added to a branch, including
those that were never added to the branch in CVS.  (CVS allows part of a
source tree to be added to a branch/tag.) (t06.sh)

- A file that was added to the source branch *after* a daughter branch
was created but before the first commit on the branch will incorrectly
be added to the daughter branch in git. (t04.sh)


Problems known to occur in the conversion of CVS tags:

Any of the above problems can affect the content of the tag, plus:

- If multiple tags mark the same revision, only one of them is included
in the conversion. (t03.sh)


Michael

[-- Attachment #2: t01.sh --]
[-- Type: application/x-sh, Size: 414 bytes --]

[-- Attachment #3: t06.sh --]
[-- Type: application/x-sh, Size: 678 bytes --]

[-- Attachment #4: t04.sh --]
[-- Type: application/x-sh, Size: 700 bytes --]

[-- Attachment #5: t03.sh --]
[-- Type: application/x-sh, Size: 448 bytes --]