[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
updates.
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,
etc.
If I don't do this, and then create another branch for testing, a file
might be version 1.1.1.1, and my test branch versions would then be on
1.1.1.1.1.X.
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 \
OTHER_VENDOR_RELEASE_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?
Ted
--
dodecatheon at gmail dot com
Frango ut patefaciam -- I break so that I may reveal
- any pitfalls of 'cvs admin -b'?,
Ted Stern <=