threads / discuss / 9533

git-cvsexportcommit getting out of sync with CVS status requests

Subject: git-cvsexportcommit getting out of sync with CVS status requests

## tl;dr

5 messages between Aug 15, 2007 and Aug 15, 2007.

replies: 4people: 4as markdown or json

Alex Bennee· Aug 15, 2007, 11:48 UTC · lore
Hi,

Occasionally (usually when a lot of files have been added or moved in my git tree) git-cvsexportcommit gets confused when I'm exporting. I'll get the error like:

File path/to/filea is already known in your CVS checkout.
But when manually querying:
$ cvs status path/to/filea
===================================================================
File: no file filea           Status: Unknown
   Working revision:    No entry for filea
   Repository revision: No revision control file
It's often combined with other errors like:

File path/to/fileb not up to date but has status 'Unknown' in your CVS checkout!

Again manually querying:
$ cvs status path/to/fileb
===================================================================
File: fileb        Status: Up-to-date
   Working revision:    1.2
   Repository revision: 1.2     /path/to/cvs/path/to/fileb,v
   Sticky Tag:          ATAG (branch: 1.2.98)
   Sticky Date:         (none)
   Sticky Options:      (none)

I'm trying to pick out how the script queries cvs but I'm no perl expert and there seems to be complex pipe->array magics going on in there. It certainly looks like it's got the cvs status for the wrong file associated with it.

I've made some hacks to the script and now I can see it does get into a funny state:

We matched File: a.sh Status: Up-to-date and store Up-to-date for path/to/a.sh We matched File: b Status: Up-to-date and store Up-to-date for path/to/c.sh We matched File: no file c.sh Status: Unknown and store Unknown for path/to/d.sh

Patches (not fixes, just instrumentation to see whats going on) attached for people who are interested.

-- 
Alex, homepage: http://www.bennee.com/~alex/
Merchandise can be shipped only upon receipt of payment.



--- git-cvsexportcommit.perl	2007-08-15 12:10:03.000000000 +0100
+++ git-cvsexportcommit	2007-08-15 12:37:50.000000000 +0100
@@ -1,4 +1,5 @@
 #!/usr/bin/perl -w
+use lib (split(/:/, $ENV{GITPERLLIB} || "/home/alexjb/share/perl/5.8.8"));
 
 # Known limitations:
 # - does not propagate permissions
@@ -173,6 +174,9 @@
 foreach my $f (@files) {
     my $path = dirname $f;
     next if (grep { $_ eq $path } @dirs);
+
+    $opt_v && print "Adding $f to files to check status of\n";
+    
     push @canstatusfiles, $f;
 }
 
@@ -185,12 +189,13 @@
     my @cvsoutput;
     @cvsoutput= safe_pipe_capture(@cvs, 'status', @canstatusfiles);
     my $matchcount = 0;
-    foreach my $l (@cvsoutput) {
-        chomp $l;
+    foreach my $cvsoutput (@cvsoutput) {
+        chomp $cvsoutput;
 
-	$opt_v && print "Processing $1\n";
+#	$opt_v && print "Processing $cvsoutput\n";
 
-        if ( $l =~ /^File:/ and  $l =~ /Status: (.*)$/ ) {
+        if ( $cvsoutput =~ /^File:/ and  $cvsoutput =~ /Status: (.*)$/ ) {
+	    $opt_v && print "We matched $cvsoutput and store $1 for $canstatusfiles[$matchcount]\n";
             $cvsstat{$canstatusfiles[$matchcount]} = $1;
             $matchcount++;
         }
@@ -201,9 +206,9 @@
 foreach my $f (@afiles) {
     if (defined ($cvsstat{$f}) and $cvsstat{$f} ne "Unknown") {
 	$dirty = 1;
-	warn "File $f is already known in your CVS checkout.\n"
-	warn "  Perhaps it has been added by another user.\n"
-	warn "  Or this may indicate that it exists on a different branch.\n"
+	warn "File $f is already known in your CVS checkout.\n";
+	warn "  Perhaps it has been added by another user?\n";
+	warn "  Or this may indicate that it exists on a different branch?\n";
 	warn "  If this is the case, use -f to force the merge.\n";
 	warn "Status was: $cvsstat{$f}\n";
     }
@@ -300,6 +305,7 @@
 # if the exec returns non-zero we die
 sub safe_pipe_capture {
     my @output;
+
     if (my $pid = open my $child, '-|') {
 	@output = (<$child>);
 	close $child or die join(' ',@_).": $! $?";
Alex Bennee· Aug 15, 2007, 12:58 UTC · re: Alex Bennee · lore

Re: git-cvsexportcommit getting out of sync with CVS status requests

On Wed, 2007-08-15 at 12:48 +0100, Alex Bennee wrote:
Show 5 quoted lines
> Hi,
> 
> Occasionally (usually when a lot of files have been added or moved in my
> git tree) git-cvsexportcommit gets confused when I'm exporting. I'll get
> the error like:

So I have figured out the reason it goes out of sync. CVS doesn't seem to always report status in the order you give it on the command line (which is rather crucial to the functioning of the script).

e.g. cvs status path/to/filea path/to/filev path/to/filec can return the status in order

fileb filea filec

It looks like running a single CVS query for each file is the only solution.

-- 
Alex Bennee - Alex.Bennee@transitive.com
Behind every great computer sits a skinny little geek.
Simon 'corecode' Schubert· Aug 15, 2007, 15:53 UTC · re: Alex Bennee · lore

Re: git-cvsexportcommit getting out of sync with CVS status requests

Alex Bennee wrote:
> It looks like running a single CVS query for each file is the only
> solution.
I think internally CVS is doing single queries anyways.  At least that was my impression.
Or we find out which order cvs is reporting the status.  Maybe a simple sort of the pathnames could be sufficient?
cheers
  simon
Johannes Schindelin· Aug 15, 2007, 16:11 UTC · re: Simon 'corecode' Schubert · lore

Re: git-cvsexportcommit getting out of sync with CVS status requests

Hi,
On Wed, 15 Aug 2007, Simon 'corecode' Schubert wrote:
Show 6 quoted lines
> Alex Bennee wrote:
> > It looks like running a single CVS query for each file is the only
> > solution.
> 
> I think internally CVS is doing single queries anyways.  At least that 
> was my impression.

Why then was cvsexportcommit so much slower without c56f0d9c661dc918a088e60d0ab69dd48019a9be?

Ciao, Dscho

Simon 'corecode' Schubert· Aug 15, 2007, 16:34 UTC · re: Johannes Schindelin · lore

Re: git-cvsexportcommit getting out of sync with CVS status requests

Johannes Schindelin wrote:
Show 7 quoted lines
>> Alex Bennee wrote:
>>> It looks like running a single CVS query for each file is the only
>>> solution.
>> I think internally CVS is doing single queries anyways.  At least that 
>> was my impression.
> Why then was cvsexportcommit so much slower without 
> c56f0d9c661dc918a088e60d0ab69dd48019a9be?
Ah, my bad.  Didn't use such a recent cvsexportcommit.  So we need to mimic the cvs sorting.
cheers
  simon

← back to recent threads