bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LockDir sometimes ignored in multi-repository config


From: Ken Poole
Subject: LockDir sometimes ignored in multi-repository config
Date: Fri, 19 Oct 2001 16:39:27 -0400

>Submitter-Id:   net
>Originator:     Ken Poole
>Organization:
net
>Confidential:  no
>Synopsis:      LockDir sometimes ignored in multi-repository config
>Severity:      serious
>Priority:      high
>Category:      cvs
>Class:         sw-bug
>Release:       1.11.1p1
>Environment:
        
System: Linux haven.spd.analog.com 2.4.3-12 #1 Fri Jun 8 13:35:30 EDT
2001 i586 unknown
Architecture: i586

>Description:
In a sandbox for which subdirectories refer to different (local)
repositories, cvs seems to use the LockDir specification from the
first config file read, and apply it to all the repositories, even
though other repositories may have different LockDir specifications.

Since the choice of lock directory is inconsistent, this can lead to
loss of data.

The test script checks out <module> from the test2 repository and then
does an update in the directory above the root of <module>, in a
directory which has no CVS subdir, and with $CVSROOT set to test1.  Cvs
seems to read only the config file for the test1 repository, not the one
for test2 which contains a LockDir specification.  You can tell that
the LockDir is ignored because a #cvs.lock dir was put in the test2
repository itself; that stops the update to wait for the lock.

The same behavior is observed when directory D contains files from
test1, and directory D/E contains files from test2, and a cvs update
is done from directory D.
>How-To-Repeat:

# Set up two repositories
% mkdir /tmp/cvstest
% mkdir /tmp/cvstest/test1
% cvs -d /tmp/cvstest/test1 init
% mkdir /tmp/cvstest/test2
% cvs -d /tmp/cvstest/test2 init
% mkdir /tmp/cvstest/test2/locks

# Set CVSROOT to point to test1
% setenv CVSROOT /tmp/cvstest/test1

# Check out CVSROOT of test2 and set a LockDir
% mkdir /tmp/cvstest/t2
% cd /tmp/cvstest/t2
% cvs -d /tmp/cvstest/test2 co CVSROOT
cvs checkout: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
% echo LockDir=/tmp/cvstest/test2/locks >> CVSROOT/config
% cvs ci -mnone CVSROOT/config 
Checking in CVSROOT/config;
/tmp/cvstest/test2/CVSROOT/config,v  <--  config
new revision: 1.2; previous revision: 1.1
done
cvs commit: Rebuilding administrative file database

# Lock the CVSROOT directory.  Due to the LockDir spec,
# this should have no effect....
% mkdir /tmp/cvstest/test2/CVSROOT/\#cvs.lock

# ... but unfortunately, it does (doing an update from
# /tmp/cvstest/t2, which has no CVS directory)
% cvs up
cvs update: Updating CVSROOT
cvs update: [15:31:12] waiting for kpoole's lock in
/tmp/cvstest/test2/CVSROOT
^Ccvs [update aborted]: received interrupt signal

# If you cd into CVSROOT, the #cvs.lock is ignored....
% cd CVSROOT/
% cvs up
cvs update: Updating .

# ... and the correct locking is done, as we can tell by placing a lock.
% mkdir /tmp/cvstest/test2/locks/CVSROOT/\#cvs.lock
% cvs up
cvs update: Updating .
cvs update: [15:32:17] waiting for kpoole's lock in
/tmp/cvstest/test2/CVSROOT
^Ccvs [update aborted]: received interrupt signal
        
>Fix:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]