any pitfalls of 'cvs admin -b'?

[Ted Stern]

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