From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040808 Firefox/0.9.3 Description of problem: when running cvs export with the -d flag and CVSROOT is set to a pserver connection, the CVS subdirectory is erroneously created in the target directory. Subsequent exports from other cvs components will fail when exporting to the same directory as the CVS structure is present. The problem does not occur when CVSROOT is set to local directory. Version-Release number of selected component (if applicable): cvs-1.11.2-24 How reproducible: Always Steps to Reproduce: 1. set CVSROOT to a pserver connection (i.e. CVSROOT=:pserver:user:pass@host/directory/to/cvsroot) 2. run "cvs export -r <version> -d <directory> <project> 3. cd to <directory> and note the CVS subdirectory Actual Results: CVS subdirectry was created in the directory specified at -d. Expected Results: CVS subdirectory should not be created as per the export functionality. Additional info: Rawhide version cvs-1.11.17-3 or newer seems to contain a fix in client.c that resolves this problem. Any chance this could be backported to RHEL 3? This is a dupe of 66733 - however that bug is listed under Red Hat 7.3 and is not getting much attention as a result.
A couple of other observations: This also happens if CVSROOT is set to an ext connection. My testing suggests that the following conditions must be met to trigger the big: - The directory specified in the -d option must already exist. - A user-applied tag must be specified in the -r option (it does not create the directory if you use -r HEAD). The workaround is not to create the directory before performing an export.
*** This bug has been marked as a duplicate of 66733 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.