threads / discuss / 4292

git-cvsserver wart?

Subject: git-cvsserver wart?

## tl;dr

8 messages between May 25, 2006 and May 26, 2006.

replies: 7people: 2as markdown or json

Cameron McBride· May 25, 2006, 16:42 UTC · lore

I'm a new git user, so if I'm doing something boneheaed - sharp kicks are welcome.

For reasons I won't go into, the ability to use cvs clients is darn near crucial. Although most development is local (where I install / use git), pulling down the latest updates and pushing up minor changes via CVS is helpful at remote locations where I don't want to maintain clients. Git with git-cvsserver makes this very nice. Thanks to all!

Now, the problem I ran into:

code/ntropy> cvs up Can't use an undefined value as an ARRAY reference at /usr/local/bin/git-cvsserver line 761. closing dbh with active statement handles cvs [update aborted]: end of file from server (consult above messages if any) code/ntropy> cvs -v Concurrent Versions System (CVS) 1.11.1p1 (client/server)

Doing a 'cvs up -dP' (or either of the two individually) seems to work fine.

so, it's an old client, a newer client doesn't have this problem. a bare 'cvs up' works fine on: Concurrent Versions System (CVS) 1.11.17 (client/server)

Just to be clear, it appears everything gets updated with the workaround - but there might be something else amiss, so I thought it was worth mentioning.

Cameron

p.s. I'm assuming the following statement is harmless (it's always present): closing dbh with active statement handles

Martin Langhoff· May 25, 2006, 21:19 UTC · re: Cameron McBride · lore

Re: git-cvsserver wart?

On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
Show 6 quoted lines
> For reasons I won't go into, the ability to use cvs clients is darn
> near crucial.  Although most development is local (where I install /
> use git), pulling down the latest updates and pushing up minor changes
> via CVS is helpful at remote locations where I don't want to maintain
> clients.  Git with git-cvsserver makes this very nice.   Thanks to
> all!
NP!

There's been some recent changes to cvsserver -- so version info is crucial. What git version are you using? Can you try with the lastest #master head from Junio? That's the latest and greatest...

If that doesn't fix it, can you post the logs? I think you have to declare CVS_LOG=/tmp/cvslog or somesuch.

> code/ntropy> cvs -v
> Concurrent Versions System (CVS) 1.11.1p1 (client/server)

We've developed it testing against 1.12.9 from debian and 1.11.20 from MacOSX/fink.

> so, it's an old client, a newer client doesn't have this problem.  a
> bare 'cvs up' works fine on:
> Concurrent Versions System (CVS) 1.11.17 (client/server)

Ah! Then capturing the logs of the working and non-working clients, and comparing them can probably help. Can you capture and post the relevant parts of the log...?

> p.s.  I'm assuming the following statement is harmless (it's always present):
> closing dbh with active statement handles

Yup. Harmless indeed. They way we are using prepared statements, I don't know how to avoid it :-/ -- suggestions welcome.

cheers,
martin
Cameron McBride· May 26, 2006, 03:11 UTC · re: Martin Langhoff · lore

Re: git-cvsserver wart?

On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> There's been some recent changes to cvsserver -- so version info is
> crucial. What git version are you using? Can you try with the lastest
> #master head from Junio? That's the latest and greatest...
sorry, my bad. This error was discovered using the git stable, v1.3.3.
 Grabbing the latest at git://git.kernel.org/pub/scm/git/git.git
showed the same problem.
> If that doesn't fix it, can you post the logs? I think you have to
> declare CVS_LOG=/tmp/cvslog or somesuch.

I'm assuming you mean the log from git-cvsserver (set via git/config with logfile=...)

Besides the log cutoff in the broken attempt, it appears the culprit is a lack of arguments being passed down as that is the only difference in the logs. Specifically, the working versions output 'Arguments : (something) ' which seemed to come from the req_Argument() subroutine around line 550 (in the case of newer CVS, the output is '--').

Anyhow, the error seems to be that $state->{args} is not getting initialized. In the newer version, there seemed to be additional uninitialized variables, e.g. $state->{prependdir}. These might be signs of some larger problem (where the $state isn't getting set properly).

To quiet it down and get it to run - a crude hack seemed to work (included below). I didn't test any of this much, nor do I really understand the whole of what's going on - my alterations just seemed to allow 'cvs up' to complete without errors or warnings from both clients. Not a very robust criteria, so please review.

Cameron
--
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5ccca4f..a52e838 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1702,6 +1702,7 @@ sub argsfromdir
 {
     my $updater = shift;

+    $state->{args} = [] unless defined($state->{args});
     $state->{args} = [] if ( scalar(@{$state->{args}}) == 1 and
$state->{args}[0] eq "." );

     return if ( scalar ( @{$state->{args}} ) > 1 );
@@ -1729,7 +1730,11 @@ sub argsfromdir
         foreach my $file ( @{$updater->gethead} )
         {
             next if ( $file->{filehash} eq "deleted" and not defined
( $state->{entries}{$file->{name}} ) );
-            next unless ( $file->{name} =~ s/^$state->{prependdir}// );
+            if( defined($state->{prependdir} ) )
+            {
+                $file->{name} =~ s/^$state->{prependdir}//;
+            }
+            next unless ( $file->{name} );
             push @{$state->{args}}, $file->{name};
         }
     }
@@ -1812,7 +1817,7 @@ sub filenamesplit
     ( $filepart, $dirpart ) = ( $2, $1 ) if ( $filename =~ /(.*)\/(.*)/ );
     $dirpart .= "/";

-    if ( $fixforlocaldir )
+    if ( $fixforlocaldir and defined($state->{prependdir}))
     {
         $dirpart =~ s/^$state->{prependdir}//;
     }
@@ -1832,7 +1837,10 @@ sub filecleanup
     }

     $filename =~ s/^\.\///g;
-    $filename = $state->{prependdir} . $filename;
+    if( defined($state->{prependdir}) )
+    {
+        $filename = $state->{prependdir} . $filename;
+    }
     return $filename;
 }
Martin Langhoff· May 26, 2006, 03:23 UTC · re: Cameron McBride · lore

Re: git-cvsserver wart?

On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> sorry, my bad. This error was discovered using the git stable, v1.3.3.
>  Grabbing the latest at git://git.kernel.org/pub/scm/git/git.git
> showed the same problem.
Ok. You might want to retain that latest, it has some further fixes ;-)
Show 5 quoted lines
> > If that doesn't fix it, can you post the logs? I think you have to
> > declare CVS_LOG=/tmp/cvslog or somesuch.
>
> I'm assuming you mean the log from git-cvsserver (set via git/config
> with logfile=...)

I was actually thinking of setting the environment at the client end: CVS_CLIENT_LOG, http://cvsbook.red-bean.com/cvsbook.html#$CVS_CLIENT_LOG but it looks like you've got it mostly sorted.

> Besides the log cutoff in the broken attempt, it appears the culprit
> is a lack of arguments being passed down as that is the only
> difference in the logs.

Yes, I was guessing as much. I am still curious about what parameters (and in what order) cvs 1.11.7 sends...

> To quiet it down and get it to run - a crude hack seemed to work

It looks reasonable as a means to shut it up, but perhaps if we can figure out what the client is telling us... ;-)

martin
Cameron McBride· May 26, 2006, 03:57 UTC · re: Martin Langhoff · lore

Re: git-cvsserver wart?

On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> Ok. You might want to retain that latest, it has some further fixes ;-)
sounds good.
> Yes, I was guessing as much. I am still curious about what parameters
> (and in what order) cvs 1.11.7 sends...
sure!  now that I know CVS_CLIENT_LOG exists ... ;)

It points in basically the same direction, which is to say the newer client passes an 'Argument -- ' which is what git-cvsserver seems to be choking on.

The 'in' versions of the two noup: cvs 1.11.1p1 that failed plane cvs update work: cvs 1.11.17 that worked

--- cvs_noup.log.in 2006-05-25 23:44:21.000000000 -0400 +++ cvs_work.log.in 2006-05-25 23:48:38.000000000 -0400

@@ -1,6 +1,7 @@
 Root /export/home/cameron/ws/git_test/ntropy.git
-Valid-responses ok error Valid-requests Checked-in New-entry Checksum
Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode
Mod-time Removed Remove-entry Set-static-directory
Clear-static-directory Set-sticky Clear-sticky Template
Set-checkin-prog Set-update-prog Notified Module-expansion
Wrapper-rcsOption M Mbinary E F MT
+Valid-responses ok error Valid-requests Checked-in New-entry Checksum
Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode
Mod-time Removed Remove-entry Set-static-directory
Clear-static-directory Set-sticky Clear-sticky Template Notified
Module-expansion Wrapper-rcsOption M Mbinary E F MT
 valid-requests
+Argument --
 Directory .
 /export/home/cameron/ws/git_test/ntropy.git/master
 Entry /.gitignore/1.1///

Thanks for your help!

Cameron
Cameron McBride· May 26, 2006, 03:24 UTC · re: Cameron McBride · lore

Re: git-cvsserver wart?

Does cvs commit upstream work? In my testing, I can't get 'cvs ci' to function on a git repo.

This seems to be broken with v1.3.3 and latest 1.3.3.ged90. The cvs clients are the same as before 1.11.1p1 and 1.11.17

The cvs client exits with: Index already exists in git repo

The log (for git version 1.3.3.ged90):

INFO - --------------- STARTING ----------------- DEBUG - Temporary directory is '/tmp/UvaWwud8fs' DEBUG - req_Root : /export/home/cameron/ws/git_test/ntropy.git DEBUG - req_Validresponses : ok error Valid-requests Checked-in New-entry Checksum Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time Removed Remove-entry Set-static-directory Clear-static-directory Set-sticky Clear-sticky Template Set-checkin-prog Set-update-prog Notified Module-expansion Wrapper-rcsOption M Mbinary E F MT DEBUG - req_validrequests DEBUG - SEND : Valid-requests remove add status Entry watchers ci tag log co Modified Questionable admin Root history valid-requests Global_option Argumentx annotate Valid-responses Unchanged Directory rlog Argument expand-modules diff editors update

                         DEBUG - SEND : ok
DEBUG - Argument : -m
DEBUG - Argument : ncsa mod
DEBUG - req_Directory : localdir=.
repository=/export/home/cameron/ws/git_test/ntropy.git/master path=
directory= module=master
 INFO  - Received entry line '/README/1.7///' => 'README'
DEBUG - Argument : README
INFO  - req_ci : [NULL]
WARN  - file 'index' already exists in the git repository

Let me know if any additional information is useful, I didn't have much time to dig into this.

Cameron
Martin Langhoff· May 26, 2006, 03:28 UTC · re: Cameron McBride · lore

Re: git-cvsserver wart?

On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> WARN  - file 'index' already exists in the git repository

This warning means that you are running git-cvsserver off a repo where you also have a checkout. git-cvsserver really expects to be running off a 'naked' or 'bare' repo. For read only ops I think it kind-of works in a 'checkout' repo, but commits are a different story.

cheers,
m
Cameron McBride· May 26, 2006, 03:34 UTC · re: Martin Langhoff · lore

Re: git-cvsserver wart?

On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
Show 7 quoted lines
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> > WARN  - file 'index' already exists in the git repository
>
> This warning means that you are running git-cvsserver off a repo where
> you also have a checkout. git-cvsserver really expects to be running
> off a 'naked' or 'bare' repo. For read only ops I think it kind-of
> works in a 'checkout' repo, but commits are a different story.

hmmm, it is supposed to be a bare repo. perhaps I flubbed something up. Can I safely delete this index file? It's in the repo.git directory. Perhaps it got created on the initial import from CVS (using cvsimport and cvsps)?

Cameron

← back to recent threads