bug-cvs
[Top][All Lists]
Advanced

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

Re: A second cvs checkout (or export) clears file locks :-(


From: Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code JSXN
Subject: Re: A second cvs checkout (or export) clears file locks :-(
Date: Tue, 27 May 2008 10:12:44 -0400
User-agent: Thunderbird 2.0.0.14 (X11/20080421)

Peter Toft wrote, On 05/26/2008 06:30 PM:
On Thu, 8 May 2008, Todd Denniston wrote:

Peter Toft wrote, On 05/08/2008 04:16 AM:
On Wed, 07 May 2008 10:27:03 +0200, Peter Toft <address@hidden> wrote:
On Wed, 07 May 2008 09:21:56 +0200, Peter Toft <address@hidden> wrote:
Hi all

I like to draw your attention towards a nasty limitation to CVS locks,
which I at least did not know until now.
I forgot to mention that I have prior to the stuff below set
cvs watch on README.txt

Best

/peter


IMHO it is a design-flaw since I could easily be in a situation,

I think what we are seeing here is a failing in the documentation, most likely because so few folks attempt to do anything resembling locking anymore (most times you just don't need it).

For non-mergeable files I need it for sure.
I fully support and acknowledge that for most files - e.g. C/C++ file locking is (way) more annoying that a general help.


OK, for non-mergeable files I understand.

After you understand how to get the commands to do what you want, could you please make a set of suggested changes to the cederqvist manual[1] and submit that back to bug-cvs, so that the edit and watchers commands might be better understood by later folks who want to use them.

The problem is not in the fine Cederqvist manual but is in CVS, this I have explained more in my bug-report : https://savannah.nongnu.org/bugs/index.php?23370

Did you try the script below?
Does the script below look like what you were trying to do? If it does not can you provide an executable script[1] to show the problems.

Also do you notice that if just after you (the user who did the edit) checkout a new copy of the baseline the file $CVSROOT/baseline/CVS/fileattr no longer exists? I believe this is due to CVS seeing this action as an abandoning of the previous sandbox, not sure if it is documented though.


[1] the one in your bug report does not qualify because it can not be cut and pasted into a command line.

The script below exhibits your "bug", which I think may be an un/misdocumented feature of CVS clearing edit on new checkout by an editing user. comments Larry|Mark|Derek??

cd /tmp/
 mkdir testcvs
 mkdir testcvs/testrepo
export CVSROOT=/tmp/testcvs/testrepo/
 cd testcvs/
 cvs init
 mkdir testrepo/baseline
 cvs checkout baseline
 cd baseline/
 touch testfile.txt
 date > testfile2.txt
cvs add testfile*
 cvs commit -m "need file"
cat $CVSROOT/baseline/CVS/fileattr


cvs edit testfile2.txt
cvs editors
#returns that I am editing testfile2.txt
cat $CVSROOT/baseline/CVS/fileattr
cd /tmp/testcvs
 mv baseline/ baseline.old
 cvs checkout baseline
cd baseline
cvs editors
#does not return that I am editing any files...
cat $CVSROOT/baseline/CVS/fileattr
#and the temporary edit marker is gone.

cd /tmp/testcvs/baseline.old
cvs edit -a edit testfile2.txt
cat $CVSROOT/baseline/CVS/fileattr
cd /tmp/testcvs/baseline
cvs editors
#returns that I am editing testfile2.txt
cat $CVSROOT/baseline/CVS/fileattr

cd /tmp/testcvs
 mv baseline/ baseline.old2
 cvs checkout baseline
cd baseline
cvs editors
#does not return that I am editing any files...


Best

Peter



[1] http://ximbiot.com/cvs/manual/
where I
like to signal that I am working on a certain file, i.e. I use cvs watch on + cvs edit but somebody asks me to export the module or test something where I need to
check out the same module in parallel to the first checkout.

I find this behaviour with CVS 1.12.13.

Is there any way to avoid this clearing of file locks?



The first thing you will need to wrap your head around is
CVS DOES NOT LOCK FILES, it puts advisory marks on them called watches.

reading  `cvs --help-commands 2>&1|grep edit`

makes it clear that the commands you want to work with only work on watched files. IIRC if someone puts a watch on a file they will get an notification if someone else does one of the actions they are watching it for, i.e., _EACH_ of the folks that might want to edit the files you are protecting (README.txt) need to do
`cvs watch add -a all README.txt`
at that point you should be able to do
`cat $CVSROOT/my_prog/CVS/fileattr` and see all those folks watching the file.

The following script I think shows how to make it work (note, I have only rarely used watchers and have never used edit&unedit):
<SNIP my original script.>
Best

Peter


 $ cvs checkout my_proj
 ... lots of check out lines...
 $ cd my_proj
 $ cvs editors             # No files will be shown since no files are
locked
 $ cvs edit README.txt
 $ cvs editors .
README.txt pto Wed May 7 06:43:15 2008 -0000 myworkstation

 /opt/cvsroot/my_proj
 $ cd ..
 $ mv my_proj my_proj_work
 $ cvs checkout -r HEAD my_proj
 $ ls -1d
 my_proj               my_proj_work
 $ cd my_proj_work
 $ cvs editors .

Bummer - the lock on my_proj/README.txt is gone.... :-((
Pure magic - but very annoying magic....

How come? Can I make some different operation, where I don't loose the
file
lock.

Note; If I replace the second "cvs checkout" with "cvs export" I have
the
same problem.


Best

Peter Toft, Ph.D. address@hidden http://petertoft.dk


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
http://www.crane.navy.mil/custfeedback




reply via email to

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