git-cvsexportcommit getting out of sync with CVS status requests

git-cvsexportcommit getting out of sync with CVS status requests

[Alex Bennee]

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

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.


[-- Attachment #2: cvsexport.patch --]
[-- Type: text/x-patch, Size: 2018 bytes --]

--- 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(' ',@_).": $! $?";

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

[Alex Bennee]

On Wed, 2007-08-15 at 12:48 +0100, Alex Bennee wrote:
> 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.

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

[Simon 'corecode' Schubert]

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

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

[Johannes Schindelin]

Hi,

On Wed, 15 Aug 2007, Simon 'corecode' Schubert wrote:

> 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

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

[Simon 'corecode' Schubert]

Johannes Schindelin wrote:
>> 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