>Submitter-Id: net
>Originator: Warwick Harvey
>Organization:
net
>Confidential: no
>Synopsis: cvs export to existing tree doesn't recurse
>Severity: non-critical
>Priority: low
>Category: cvs
>Class: sw-bug
>Release: cvs-1.10 (also 1.10.2)
>Environment:
Pentium 166 running RedHat Linux
Libraries:
libcrypt-2.0.7.so
libc-2.0.7.so
ld-2.0.7.so
Also a SPARC Solaris machine (sparc_sunos5)
System: Linux pinner.icparc.ic.ac.uk 2.0.36 #6 Thu Jan 7 11:54:56 GMT 1999 i586 unknown
Architecture: i586
>Description:
If you export a CVS module (with subdirectories) into a directory
somewhere, and then repeat the export, only the root of the tree is
updated; the subdirectories are ignored (other than being listed in
the output with a `?' next to them). It's as if `-l' has been
specified, and `-R' doesn't fix the problem.
The same thing happens if you try to export into an existing (empty)
directory tree. (This may be more of a problem if you want to
export multiple modules which share directories? I haven't
investigated that one though.)
Note that if a CVS subdirectory (with appropriate contents) exists
in a particular subdirectory, it may export files to that
subdirectory (depending on the contents of the Entries file), but
the CVS subdirectory is /deleted/ afterwards. (Actually, this seems
more serious: if a user accidentally exports to a working
repository, they hose all their CVS administration files --- but
probably they'd have more serious problems in this case anyway.)
>How-To-Repeat:
One sequence of commands used to exhibit the bug:
cvs export -D "2000-05-25 13:02" Eclipse
cvs export -D "2000-05-25 13:02" Eclipse
(That is, simply repeating an export of a module which has
subdirectories.)
>Fix:
Unknown. It /appears/ as though CVS is looking for, creating and
using CVS subdirectories during the export, presumably treating
it as an `update -d', and then deleting the CVS subdirectories
afterwards. Apparently this approach requires a little more care if
the export is to an existing directory tree.
