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

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code JSXN]

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