[PATCH] git-cvsserver: handle change type T

[PATCH] git-cvsserver: handle change type T

[Paolo Bonzini]

git-cvsserver does not support changes of type T (file type change,
e.g. symlink->real file).  This patch treats them the same as changes
of type M.
---
 git-cvsserver.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index afe3d0b..1b6b20e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2633,7 +2633,7 @@ sub update
                     };
                     $self->insert_rev($name, $head->{$name}{revision}, $hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
                 }
-                elsif ( $change eq "M" )
+                elsif ( $change eq "M" || $change eq "T" )
                 {
                     #$log->debug("MODIFIED $name");
                     $head->{$name} = {
-- 
1.5.3.4.910.gc5122-dirty

Re: [PATCH] git-cvsserver: handle change type T

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> git-cvsserver does not support changes of type T (file type change,
> e.g. symlink->real file).  This patch treats them the same as changes
> of type M.

Hmm.

Do cvs clients even know how to handle symlinks, or will this patch just
start sending the readlink(2) result as if it is just a regular file
contents?

Re: [PATCH] git-cvsserver: handle change type T

[Paolo Bonzini]

Junio C Hamano wrote:
> Paolo Bonzini <bonzini@gnu.org> writes:
> 
>> git-cvsserver does not support changes of type T (file type change,
>> e.g. symlink->real file).  This patch treats them the same as changes
>> of type M.
> 
> Hmm.
> 
> Do cvs clients even know how to handle symlinks, or will this patch just
> start sending the readlink(2) result as if it is just a regular file
> contents?

It was before too.  The problem arises if one found the problem, deleted 
the symlink, added the regular file -- and now cvsserver stops working 
at all. :-(

Paolo

Re: [PATCH] git-cvsserver: handle change type T

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> Junio C Hamano wrote:
>> Paolo Bonzini <bonzini@gnu.org> writes:
>>
>>> git-cvsserver does not support changes of type T (file type change,
>>> e.g. symlink->real file).  This patch treats them the same as changes
>>> of type M.
>>
>> Hmm.
>>
>> Do cvs clients even know how to handle symlinks, or will this patch just
>> start sending the readlink(2) result as if it is just a regular file
>> contents?
>
> It was before too.  The problem arises if one found the problem,
> deleted the symlink, added the regular file -- and now cvsserver stops
> working at all. :-(

I fully agree that "stops working at all" was baaaaad, and your patch may
be an improvement.

What I am questioning is what the code should do (IOW, what would be good
for cvs clients to see).  Should it send a symlink as a regular file, or
simply just omit it?  If the answer is "the former", then we do not have
to worry about it any further after applying your patch.  Otherwise we
still have to do something _else_ after applying your patch.  I did not
know which way we would want to proceed, and I still don't.

Re: [PATCH] git-cvsserver: handle change type T

[Paolo Bonzini]

> What I am questioning is what the code should do (IOW, what would be good
> for cvs clients to see).  Should it send a symlink as a regular file, or
> simply just omit it?  If the answer is "the former", then we do not have
> to worry about it any further after applying your patch.  Otherwise we
> still have to do something _else_ after applying your patch.  I did not
> know which way we would want to proceed, and I still don't.

The reason why my patch was enough for me, is that users would just use 
the cvs bridge to stay up-to-date, not to spelunk the history (maybe to 
spelunk it with annotate, but not to look at old versions etc.).  For 
that, all I need is that current checkouts are okay.  We have to decide 
if other cvsserver use cases are common enough.

If they are, I think the optimal way to proceed could be to detect 
relative symlinks and resolve them (sending the linked file's content), 
and do "something else" (omit it, send the destination path as a regular 
file?) for absolute symlinks.

Paolo

Re: [PATCH] git-cvsserver: handle change type T

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> Junio C Hamano wrote:
> ...
>> Do cvs clients even know how to handle symlinks, or will this patch just
>> start sending the readlink(2) result as if it is just a regular file
>> contents?
>
> It was before too.  The problem arises if one found the problem,
> deleted the symlink, added the regular file -- and now cvsserver stops
> working at all. :-(

Yeah, I see why $git_perms fall back to "rw" now around l.2620 -- if file
mode is 120000, none of the r/w/x would have been added in.

Martin, likes, dislikes?

Re: [PATCH] git-cvsserver: handle change type T

[Martin Langhoff]

On Mon, Mar 17, 2008 at 9:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
>  Martin, likes, dislikes?

Hmmm. Trying to make up my mind on this. It looks like symlink support
is broken in cvsserver, it is something we did not even consider, so I
am trying to visualise _how_ broken it is, and what it would take to

 - refuse to handle symlinks (temporarily, until we can guarantee our
handling is sane)
 - translate symlinks that are internal - hard, and probably not even
a good idea
 - handle symlinks directly - is the client safe from malicious symlinks?

I have never used symlinks with either git or cvs, so I am unsure as
to whether their handling is compatible. Do either of them perform any
sanity checks on the targetof the symlink?

cheers,



m

Re: [PATCH] git-cvsserver: handle change type T

[Paolo Bonzini]

> I have never used symlinks with either git or cvs, so I am unsure as
> to whether their handling is compatible. Do either of them perform any
> sanity checks on the targetof the symlink?

I doubt that CVS actually supports symlinks.  git makes no sanity checks.

Paolo