Alex Chaffee wrote :
|| 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?
"cvs add" is not unique here. "cvs commit", for example, is an all
or nothing command where being unable to process one argument aborts
the whole command. For commit, this is clearly the right choice.
For the current implementation of add it is also the right choice
(because add currently is modifying the repository), but as part of
excising the repository changing that could certainly be
reconsidered.
To make add work individually on a list is actually not as hard as
the workaround you discuss with find above:
for i in *
do
cvs add $i
done
which does a separate "cvs add" for each item, so no failure prevents
the other additions form succeeding.
|| 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.
This sounds like a bug. "cvs add CVS" should reject tha add; and
then "cd CVS; cvs add Repository" should fail because there is no CVS
sub-directory. Doing "cvs add CVS/Repository" is currently not
permitted. How did you make it work?
|| Are there plans for cvs to do more strict argument checking to make
|| sure you're not mistakenly messing with the magic CVS directory?
At first glance, the existing checks ought to be enough, but
obviously you've found a way around them.
Any change that will permit "cvs add" to take an argument containing
a slash will have to be careful to preserve the existing check, as
will "cvs add foo" if it is going to add . and .. and ../.. etc as
managed directories (so it not only has to search up to find them but
also has to ensure that none of the names coming back down is 'CVS').
Hmm, here's an off the top of my head way of adding * while
precluding CVS sub-directories while living with the current "no
slash" restricted form of "cvs add":
find . -print \
| grep -v '/CVS$' \
| grep -v '/CVS/' \
| while read target
do
dir=`dirname $target`
targ=`basename $target`
(
cd $dir
cvs add $targ
)
done
It lists everything below the current dir, removes from the list
anything named CVS or within a directory named CVS. For each
remaining item it uses a sub-shell to cd into the enclosing directory
and add the item. The enclosing directory might be '.', but there
always is one explicitly there in $target for dirname to find. The
sub-shell is used so that the cd does not affect the processing of
subsequent items.
--
Anyone who can't laugh at himself is not | John Macdonald
taking life seriously enough -- Larry Wall | [EMAIL PROTECTED]
