[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 <pto@linuxbog.dk> wrote:
On Wed, 07 May 2008 09:21:56 +0200, Peter Toft <pto@linuxbog.dk> 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. [pto@linuxbog.dk] 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