Git-cvsimport is written in perl, which understandably
causes the tests to fail if you build with NO_PERL (which
will avoid building cvsimport at all). The earlier cvsimport
tests in t9600-t9602 are all marked with a PERL
prerequisite, but these ones are not.
The one in t9603 was likely not noticed because it is an
expected failure anyway.
The ones in t9604 have been around for a long time, but it
is likely that the combination of NO_PERL and having cvsps
installed is rare enough that nobody noticed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixed all places where it was a straightforward change from cd'ing into a
directory and back via "cd .." to a cd inside a subshell.
Found these places with "git grep -w "cd \.\.".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some tests in t96xx series (cvsimport) want to write into the control area
(CVSROOT) of their test CVS repositories, but this does not work well when
the source area is made read-only (test trash directories are moved via
--root=else/where option).
Copy the supplied test CVS repository to a scratch place at the beginning
of these tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes sure that timestamps and ordering on branches is not influenced
by a fix for cvsps.
The test extension does not deal which patchset correction on branches it
only verifes that branches are basically handled as before.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some cvs repositories may have time deviations in their recorded commits.
This is a test for one of such cases. These kind of repositories can happen
if the system time of cvs clients is not fully synchronised.
Consider the following sequence of events:
* client A commits file a r1.1
* client A commits file a r1.2, b r1.1
* client B commits file b r1.2 using the same timestamp as a r1.1
This can be resolved but due to cvsps ordering its patchsets solely based
on the timestamp. It only takes revision odering into account if there
is no difference in the timestamp.
I hit this bug when importing from a real repository which was originally
converted from another rcs based scm. Other import tools can handle this
correctly, e.g. parsecvs.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
