[Top][All Lists]

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

More Info: CVS Import Inaccuracies

From: Oproescu Bogdan (KTXA 3)
Subject: More Info: CVS Import Inaccuracies
Date: Thu, 11 Aug 2005 15:54:18 +0200

   Hello Bernd, 

   Thanks for your message below: the "cvs checkout -R" 
   is a typo below, I meant "cvs checkout -r", and as I 
   told Larry Jones a few minutes ago, I knew about the 
   Vendor and Release Tags params to "cvs import", but I 
   was not sure what happens when these 2 tags stay the same. 
   The result is that indeed the files removed locally prior 
   to importing are not detected by CVS. 

   I think we can close this issue, as all is clear now. 

   Cheers, Bogdan 

   Bogdan Oproescu   

   Technology & Services
   Advanced Middleware &
   Development Environments KTXA 3 
   Postfach 600
   CH-8070 Z├╝rich
   Tel.: +41 1 334 6846
   Fax.:+41 1 332 8024
   E-Mail: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: Bernd Jendrissek [mailto:berndj@prism.co.za] 
Sent: Wednesday, August 10, 2005 5:34 PM
To: Oproescu Bogdan (KTXA 3)
Cc: 'bug-cvs@nongnu.org'; 'Todd Denniston'
Subject: Re: CVS Import Inaccuracies - Please Respond

Hash: SHA1

On Wed, Aug 10, 2005 at 04:31:10PM +0200, Oproescu Bogdan (KTXA 3) wrote:
>    What is going on here?? Why is CVS checking out the "file_1.txt"
>    and "file_new.txt" files? Or is it because they ARE the HEAD
>    Revisions of these files in the "server_test_module" module, since
>    CVS did not increment the Version Numbers of the remaining files in
>    my structure above for the 2nd to Nth CVS Imports, which did not
>    include "file_1.txt" and "file_new.txt"??

That would be my guess - there is no way, during import, to tell CVS
"this file is NOT present".

>    Here, we either have another CVS Bug, or at least a very inaccurate
>    way to do cvs imports. Note that I can repeat this test using the
>    command "cvs checkout -R HEAD server_test_module" and get the same
>    results as before, so this is not the reason. Worse yet, we cannot
>    even specify exactly which files we want from our "cvs import" with
>    the "-R" flag on checkouts. 

cvs checkout -R HEAD server_test_module
  will checkout HEAD (module name!) server_test_module *R*ecursively.
  In fact, I get this:

cvs server: cannot find module `HEAD' - ignored
cvs [checkout aborted]: cannot expand modules

cvs checkout -r HEAD server_test_module
  will checkout HEAD *r*evision of module server_test_module.

Note difference in case!

When you do import, you specify vendortag, no?  Why don't you checkout
with that?  cvs checkout -r vendortag42 server_test_module

Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org


reply via email to

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