I'm afraid to bring up a new thread involving "cvs add." Please don't
anyone start saying mean things about my family, OK?
I just had the experience of bringing a large set of Java source files
under CVS revision control. I couldn't use "cvs import" because they
had a lot of overlapping subdirectories (Java package hierarchies). I
ended up doing "cvs add *" a lot. This led to two big problems:
1. When one of the * arguments was a directory, and that directory
already had a "CVS" directory, the add was *aborted*, and the rest of
the files on the command line failed to be added. All other cvs
commands that take multiple arguments treat each argument
independently; if there's a failure it just spits out a warning and
then proceeds to try the rest of the arguments. The aborting behavior
of "add" led to inconsistencies I had to resolve manually -- I had to
say "cvs add `find * -type f -maxdepth 0`" or other such nonsense.
Are there any special reasons why "cvs add" aborts for extant
directories, but not for extant files?
2. While it seems to deal OK with the basic case of "cvs add CVS", if
you have a "find" script running that tries the equivalent of "cvs add
CVS/Repository" or whatever, you get a bogus entry in Entries:
"D/CVS///". Then on "cvs update" it tries to create this directory,
leading too "foo/CVS/CVS/..." and other such nonsense, and many
spurious error messages and weirdness.
Are there plans for cvs to do more strict argument checking to make
sure you're not mistakenly messing with the magic CVS directory?
Cheers -
- Alex
