info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Checkout/Update: behavior changed from 1.11 to 1.11.1p1 !


From: Yves Martin
Subject: Checkout/Update: behavior changed from 1.11 to 1.11.1p1 !
Date: Tue, 20 Jul 2004 11:55:32 +0200
User-agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.3

   Hello,

 I'm in a great trouble when I migrate from two CVS versions (same
 repository):
 - From cvs 1.11 on Mandrake 8.0 (RPM package cvs-1.11-5mdk)
 - To   cvs 1.11.1p1 on Debian 3.0 (Deb package 1.11.1p1debian-9woody2)

Here is a short example to describ my problem:

 Repository (2 modules/directories in a single module1/) :
   module1/dir1
   module1/dir2

 CVSROOT/modules (an alias to get "dir1" at the right place):
   alias-dir1 -d local1/local2/local3/dir1  module1/dir1

First client: checkout with cvs 1.11 (Mdk):
   local1/CVS/Repository               ==   CVSROOT/Emptydir
   local1/local2/CVS/Repository        ==   CVSROOT/Emptydir
   local1/local2/local3/CVS/Repository        ==   CVSROOT/Emptydir
   local1/local2/local3/dir1/CVS/Repository   ==   module1/dir1

Second client: checkout with cvs 1.11.1p1 (Debian):
   local1/CVS/Repository               ==   CVSROOT/Emptydir
   local1/local2/CVS/Repository        ==   .
   local1/local2/local3/CVS/Repository        ==   module1
   local1/local2/local3/dir1/CVS/Repository   ==   module1/dir1

 And I just said: Argh !! Why such a mess ! (something like that in
 french)

 What is really annoying for end-users:

 - before (1.11), the update -d in "local3" directory does not get
   "dir2" from module1/

 - after (1.11.1p1), the update -d in "local3" directory get "dir2" !

 And even worse: if an update -d is done in "local2", does "." mean
 the client get the whole /cvsroot content ?? (not tested in fact)

 Of course, my example is "simple" to describe the problem. In the
 real life, users see a completely new CVS behavior (an simple update
 now retreive many modules that were not expected) and the number of
 modules concerned is far more than two.

 I know that a solution should be to use "cvs checkout" with the alias
 name all the time (and never use "cvs update -d"). But such a command
 is not easy to do with CVS client programs (not to mention it WinCVS)
 and it is difficult to compell users to adapt.

 I have already planed to move modules on the server and change
 aliases to get a better situation (but not identical to the first
 configuration). 
 So I need answers:

 - was it a big bug in 1.11 that were corrected ?

 - is it a bug corrected in a newer version ? (I planned to migrate
   another server to 1.11.17, so I'd like to know...)

 Finally I was used to the 1.11.1 behavior and I find it strange not
 to be able to "fix" checkouted modules from alias even with the -d
 update option (see FAQ concerning Entries.Static). And I find that
 "bug" (or behavior) really cool: CVSROOT/Emptydir is the behavior I
 was always looking for:
 - your checkouted modules are fixed (at that level directory) even
   with -d update option
 - if you want a new module at that level, you just do a new checkout.

 Why a behavior more likely than the other ?

 Thank you in advance for any answer
 Best regards,
 (Sorry for my poor english - see .fr ;) - I hope I'm understandable)
-- 
Yves Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]