[Top][All Lists]

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

any pitfalls of 'cvs admin -b'?

From: Ted Stern
Subject: any pitfalls of 'cvs admin -b'?
Date: Wed, 14 Dec 2005 10:51:59 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Say that I am tracking 3rd party sources, with very infrequent

I start the module (with env variable CVSROOT set) using

    cd srcdir
    cvs import modulepath vendor-branch-tag VENDOR_RELEASE_TAG

I have seen some advice that recommends, when not tracking 3rd-party
sources, that you do

    cvs import ... # as above

    cd workdir
    cvs checkout modulepath
    cd modulepath
    cvs admin -b
    cvs update -A

This sets the HEAD branch to 1, and default checkouts to 1.1, 1.2,

If I don't do this, and then create another branch for testing, a file
might be version, and my test branch versions would then be on

If I follow that advice above, a file on my new test branch then might
have version number 1.1.2.x (branch 1.1.2), which would certainly be
less confusing.

So now I have some questions:

1) why isn't this the default?  Why wouldn't you want the 1 branch and
   1.x versions to be the default versions checked out?

2) if I started branches without using the 'admin -b' trick, and then
   I switch to the other style, could I get into deep doodoo?  If so,
   how would I undo the mistake?

3) Say I'm tracking changes from more than one 3rd-party, but I want
   to import the new vendor's changes on the trunk.  Can I use cvs
   import like this:

      cd srcdir
      cvs import -b 1 modulepath other-vendor-branch-tag \

   In the past, I've used the import -b option 1.1.3 to differentiate
   from the default 1.1.1.  But it would be nice to import the new
   files straight into 1.x versions.  Could I use HEAD as the vendor
   branch tag instead of using a -b option?

 dodecatheon at gmail dot com
 Frango ut patefaciam -- I break so that I may reveal

reply via email to

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