git-cvsserver wart?

git-cvsserver wart?

[Cameron McBride]

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

Re: git-cvsserver wart?

[Martin Langhoff]

On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> 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

Re: git-cvsserver wart?

[Cameron McBride]

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;
 }

Re: git-cvsserver wart?

[Martin Langhoff]

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 ;-)

> > 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

Re: git-cvsserver wart?

[Cameron McBride]

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

Re: git-cvsserver wart?

[Martin Langhoff]

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

Re: git-cvsserver wart?

[Cameron McBride]

On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 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

Re: git-cvsserver wart?

[Cameron McBride]

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