On 6/17/07, Frank Lichtenheld <frank@xxxxxxxxxxxxxx> wrote:
On Sun, Jun 17, 2007 at 10:10:51AM +0100, Dirk Koopman wrote: > Frank Lichtenheld wrote: > >On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote: > >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. Let me rephrase that (after actually looking through the code): All of the revision handling code assumes that.
Exactly. cvsserver emulates CVS on a single HEAD, that's why you use the headname as the 'module' parameter you pass to CVS when doing a checkout. ...
Hmm, so you did the cvs update in an old working copy of the original CVS repository? Then CVS sent those version numbers from the CVS/Entries file to the server, cvsserver certainly never generates numbers like that. And I would be very suprised if you could do anything remotely useful with abusing the old working copy this way...
Agreed - that's not really supported. Now, I'd _love_ to have a bit of time to implement CVS-style branch support to cvsserver (so a check for valid version numbers that have more dots would be a good thing), but it's hard hard hard, specially because there are many ambiguities to resolve. It would enormously useful to have branch support together with support for a bit of "version skew" so that you can replace a real CVS server with cvsserver and have people continue using the old cvs checkouts -- because the file versions and branches match. As things stand, I want to say thanks to Frank for giving cvsserver some love :-) cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
