Bug 130834

Summary:	cvs export erroneously creates CVS subdirectory
Product:	Red Hat Enterprise Linux 3	Reporter:	Rick Johnson <htmlspinnr>
Component:	cvs	Assignee:	Martin Stransky <stransky>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 19:05:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rick Johnson 2004-08-25 00:21:13 UTC

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.

Comment 1 Graham Bleach 2004-09-28 10:42:45 UTC

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.

Comment 2 Martin Stransky 2005-03-10 12:59:52 UTC


*** This bug has been marked as a duplicate of 66733 ***

Comment 3 Red Hat Bugzilla 2006-02-21 19:05:15 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.