threads / rfc / 24743

RFC patchgit-cvsimport

Subject: [BUG RFC/PATCH] git-cvsimport

## tl;dr

6 messages between Aug 14, 2010 and Aug 16, 2010. Diffs are folded; open one to read it.

replies: 5people: 4as markdown or json

Ævar Arnfjörð Bjarmason· Aug 14, 2010, 15:33 UTC · lore
This is more of a BUG than a RFC/PATCH.

Now that Junio has applied my patch to not write test results under harness I can:

    sudo chown -R root t

And run the tests with --root=/dev/shm under prove, except for 3 git-cvsimport tests. I have pending patches to these, after they'll get in I'll fix that.

But the reason they hang is interesting:
    rm -rf /tmp/meh;
    git init /tmp/meh &&
    cd /tmp/meh &&
    sudo chown -R root /home/avar/g/git/t/t9601/cvsroot &&
    cvsps --norc -q --cvs-direct -u -A --root
/home/avar/g/git/t/t9601/cvsroot module
    Initialized empty Git repository in /tmp/meh/.git/

cvsps will just hang due to the unfriendly chmod. Maybe we want something like the below to deal with that.

However, even then it'll still hang on something else, I haven't looked into what. I'm just going to fix this by having it copy the things it needs to the --root directory.

 git-cvsimport.perl |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)
Show changes to git-cvsimport.perl +19 −2
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 9e03eee..1a93fb4 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -688,8 +688,25 @@ unless ($opt_P) {
        }
        ($cvspsfh, $cvspsfile) = tempfile('gitXXXXXX', SUFFIX => '.cvsps',
                                          DIR => File::Spec->tmpdir());
-       while (<CVSPS>) {
-           print $cvspsfh $_;
+       # Alarm because "cvsps --norc -q --cvs-direct -u -A --root
+       # /home/avar/g/git/t/t9601/cvsroot module" will hang forever if
+       # the "t9601/cvsroot" directory isn't writable by us.
+       {
+               my $got_input;
+               my $start = time;
+               local $SIG{ALRM} = sub {
+                       unless ($got_input) {
+                               die sprintf "cvsps left us hanging for
%d seconds, do you have permission to write to %s?",
+                                   time() - $start,
+                                   $opt_d;
+                       }
+               };
+               alarm 10;
+               while (<CVSPS>) {
+                       $got_input = 1;
+                       print $cvspsfh $_;
+               }
+               alarm 0;
        }
        close CVSPS;
        $? == 0 or die "git cvsimport: fatal: cvsps reported error\n";
Jonathan Nieder· Aug 14, 2010, 21:09 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [BUG RFC/PATCH] git-cvsimport

Ævar Arnfjörð Bjarmason wrote:
> cvsps will just hang due to the unfriendly chmod.
Could this be fixed in cvsps[1]?

(Afterwards, it might still make sense to look into workarounds, of course.)

[1] http://ydirson.free.fr/en/software/scm/cvsps.html
Ævar Arnfjörð Bjarmason· Aug 14, 2010, 21:39 UTC · re: Jonathan Nieder · lore

Re: [BUG RFC/PATCH] git-cvsimport

On Sat, Aug 14, 2010 at 21:09, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 5 quoted lines
> Ævar Arnfjörð Bjarmason wrote:
>
>> cvsps will just hang due to the unfriendly chmod.
>
> Could this be fixed in cvsps[1]?
Maybe, but that's a hairy beast I'm not going to tackle :)

The main intent was actually just to get this into the collective memory of the list archive, this sort of thing probably never happens in the wild, and the added alarm/die complexity of dealing with it probably isn't worth the effort.

I'm going to fix up the test though, once Junio merges my other patches, which would conflict with this.

Michael Haggerty· Aug 16, 2010, 04:24 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [BUG RFC/PATCH] git-cvsimport

Ævar Arnfjörð Bjarmason wrote:
Show 27 quoted lines
> This is more of a BUG than a RFC/PATCH.
> 
> Now that Junio has applied my patch to not write test results under
> harness I can:
> 
>     sudo chown -R root t
> 
> And run the tests with --root=/dev/shm under prove, except for 3
> git-cvsimport tests. I have pending patches to these, after they'll
> get in I'll fix that.
> 
> But the reason they hang is interesting:
> 
>     rm -rf /tmp/meh;
>     git init /tmp/meh &&
>     cd /tmp/meh &&
>     sudo chown -R root /home/avar/g/git/t/t9601/cvsroot &&
>     cvsps --norc -q --cvs-direct -u -A --root
> /home/avar/g/git/t/t9601/cvsroot module
>     Initialized empty Git repository in /tmp/meh/.git/
> 
> cvsps will just hang due to the unfriendly chmod. Maybe we want
> something like the below to deal with that.
> 
> However, even then it'll still hang on something else, I haven't
> looked into what. I'm just going to fix this by having it copy the
> things it needs to the --root directory.

My guess is that cvsps is using CVS commands to access the test CVS repository, and that CVS wants to write to the file CVSROOT/history to log what is being done. The logging behavior can be turned off either:

* by using the "-R" option when invoking CVS.  This is a global option,
meaning that it has to appear before the subcommand: "cvs -R update"
rather than "cvs update -R".
* by setting the "$CVSREADONLYFS" environment variable.

Apparently -R and "$CVSREADONLYFS" were added in CVS 1.12.1, which was released in 2003.

Michael
Junio C Hamano· Aug 16, 2010, 16:25 UTC · re: Michael Haggerty · lore

Re: [BUG RFC/PATCH] git-cvsimport

Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 6 quoted lines
> My guess is that cvsps is using CVS commands to access the test CVS
> repository, and that CVS wants to write to the file CVSROOT/history to
> log what is being done.  The logging behavior can be turned off either:
> ...
> Apparently -R and "$CVSREADONLYFS" were added in CVS 1.12.1, which was
> released in 2003.

That unfortunately does not solve much. t9602 seems to want to create a new CVSROOT/val-tags file, so if Ævar wants to keep the source tree read-only, the test CVS repository needs to be copied to a scratch place.

Perhaps something like this? I actually have to wonder why cvsIMPORT needs to write into anywhere, though.

-- >8 --
Subject: cvs tests: do not touch test CVS repositories shipped with source

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>
---
 t/Makefile                         |    1 -
 t/lib-cvs.sh                       |    6 ++++++
 t/t9601-cvsimport-vendor-branch.sh |    3 +--
 t/t9602-cvsimport-branches-tags.sh |    3 +--
 t/t9603-cvsimport-patchsets.sh     |    3 +--
 5 files changed, 9 insertions(+), 7 deletions(-)
Show changes to 5 files +9 −7

t/Makefile, t/lib-cvs.sh, t/t9601-cvsimport-vendor-branch.sh, t/t9602-cvsimport-branches-tags.sh, t/t9603-cvsimport-patchsets.sh

diff --git a/t/Makefile b/t/Makefile
index cf5f9e2..876d2ca 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -28,7 +28,6 @@ pre-clean:
 
 clean:
 	$(RM) -r 'trash directory'.* test-results
-	$(RM) t????/cvsroot/CVSROOT/?*
 	$(RM) -r valgrind/bin
 
 aggregate-results-and-cleanup: $(T)
diff --git a/t/lib-cvs.sh b/t/lib-cvs.sh
index 648d161..b51d2e1 100644
--- a/t/lib-cvs.sh
+++ b/t/lib-cvs.sh
@@ -30,6 +30,12 @@ case "$cvsps_version" in
 	;;
 esac
 
+setup_cvs_test_repository () {
+	CVSROOT="$(pwd)/.cvsroot" &&
+	cp -r "$TEST_DIRECTORY/$1/cvsroot" "$CVSROOT" &&
+	export CVSROOT
+}
+
 test_cvs_co () {
 	# Usage: test_cvs_co BRANCH_NAME
 	rm -rf module-cvs-"$1"
diff --git a/t/t9601-cvsimport-vendor-branch.sh b/t/t9601-cvsimport-vendor-branch.sh
index 3afaf56..b23479f 100755
--- a/t/t9601-cvsimport-vendor-branch.sh
+++ b/t/t9601-cvsimport-vendor-branch.sh
@@ -34,8 +34,7 @@
 test_description='git cvsimport handling of vendor branches'
 . ./lib-cvs.sh
 
-CVSROOT="$TEST_DIRECTORY"/t9601/cvsroot
-export CVSROOT
+setup_cvs_test_repository t9601
 
 test_expect_success 'import a module with a vendor branch' '
 
diff --git a/t/t9602-cvsimport-branches-tags.sh b/t/t9602-cvsimport-branches-tags.sh
index 67878b2..ed01d8a 100755
--- a/t/t9602-cvsimport-branches-tags.sh
+++ b/t/t9602-cvsimport-branches-tags.sh
@@ -6,8 +6,7 @@
 test_description='git cvsimport handling of branches and tags'
 . ./lib-cvs.sh
 
-CVSROOT="$TEST_DIRECTORY"/t9602/cvsroot
-export CVSROOT
+setup_cvs_test_repository t9602
 
 test_expect_success 'import module' '
 
diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh
index 958bdce..93c4fa8 100755
--- a/t/t9603-cvsimport-patchsets.sh
+++ b/t/t9603-cvsimport-patchsets.sh
@@ -14,8 +14,7 @@
 test_description='git cvsimport testing for correct patchset estimation'
 . ./lib-cvs.sh
 
-CVSROOT="$TEST_DIRECTORY"/t9603/cvsroot
-export CVSROOT
+setup_cvs_test_repository t9603
 
 test_expect_failure 'import with criss cross times on revisions' '
 
Ævar Arnfjörð Bjarmason· Aug 16, 2010, 17:43 UTC · re: Junio C Hamano · lore

Re: [BUG RFC/PATCH] git-cvsimport

On Mon, Aug 16, 2010 at 16:25, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> My guess is that cvsps is using CVS commands to access the test CVS
>> repository, and that CVS wants to write to the file CVSROOT/history to
>> log what is being done.  The logging behavior can be turned off either:
>> ...
>> Apparently -R and "$CVSREADONLYFS" were added in CVS 1.12.1, which was
>> released in 2003.
>
> That unfortunately does not solve much.  t9602 seems to want to create a
> new CVSROOT/val-tags file, so if Ævar wants to keep the source tree
> read-only, the test CVS repository needs to be copied to a scratch place.
>
> Perhaps something like this?  I actually have to wonder why cvsIMPORT
> needs to write into anywhere, though.

That looks good. It's pretty much exactly what I was going to submit, but I was waiting until you applied my other patches to pu (since they'd with that patch as I changed the setup code in the skip patches too).

← back to recent threads