git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dirk Koopman <djk@tobit.co.uk>
To: Frank Lichtenheld <frank@lichtenheld.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
Date: Sun, 17 Jun 2007 10:10:51 +0100	[thread overview]
Message-ID: <4674FA9B.10806@tobit.co.uk> (raw)
In-Reply-To: <20070617081959.GD1828@planck.djpig.de>

Frank Lichtenheld wrote:
> Hi.
> 
> On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote:
>> Early cvs clients don't cause state->{args} to be initialised,
>> so force this to occur.
>> Some revision checking code assumes that revisions will be
>> recognisably numeric to perl, Branches are not, because they
>> have more decimal points (eg 1.2.3.4 instead of just 1.2). 

<snip>

> 
> Hmm, I don't see how you could have a problem with that since cvsserver
> doesn't support branches and never generates any revision numbers in
> that format?
> 
> There is probably much more code out there in cvsserver that does assume
> that revision is always a simple integer.
> 
> And again that comment is a but much IMHO.
> 

The specific issue that I was trying to solve is that I have (in CVS 
terms) a main line (git head: master) and an active CVS development 
branch and git head (called SR [for the sake of argument]).

I have imported both into git using cvsimport. For compatibility (and 
windows users) I need a anonymous, read only, :pserver: CVS 
implementation that can serve either head.

The version numbers in the CVS import on branch SR are standard CVS 
single level branch 1.2.3.4. Doing a 'cvs update' on this branch was 
causing all sorts of warnings about 1.2.3.4 not being numeric on that 
test. After changing the test, the warnings have gone away and it all 
still seems to work.

Having said that, I haven't worked out where cvsserver is getting those 
version numbers from in the first place, but it obviously knows that it 
is dealing with a branch sufficient to work well enough for my needs.

Of course, quite what happens when the branch merges back and people 
want to 'cvs update -A', I shall leave for the future...

Groetjes  Dirk

  reply	other threads:[~2007-06-17  9:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-16 18:50 [PATCH] cvsserver: fix legacy cvs client and branch rev issues Dirk Koopman
2007-06-17  8:19 ` Frank Lichtenheld
2007-06-17  9:10   ` Dirk Koopman [this message]
2007-06-17 10:37     ` Frank Lichtenheld
2007-06-17 16:53       ` Dirk Koopman
2007-06-17 17:20         ` Frank Lichtenheld
2007-06-17 21:27       ` Martin Langhoff
2007-06-17  8:31 ` [PATCH] cvsserver: always initialize state in argsplit() Frank Lichtenheld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4674FA9B.10806@tobit.co.uk \
    --to=djk@tobit.co.uk \
    --cc=frank@lichtenheld.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).