bug-cvs
[Top][All Lists]
Advanced

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

cvs unedit failing with 1.12.13


From: Peter Toft
Subject: cvs unedit failing with 1.12.13
Date: Thu, 27 Aug 2009 16:08:33 +0200

Dear all

I have a nasty problem with my "old-and-faithful" CVS version 1.12.13.

I have two files "FileA" and "FileB", where I use locking "cvs watch on".
The files are in different parts of a directory structure.
Assume that I have two sandboxes, and the files have been cvs
commit'ed many times.

In Sandbox A I do
$ cvs edit FileA
$ date > FileA # Just to get whatever new content in the file
With "cvs editors FileA" and "cvs status FileA" I see my self as
editor and that the file is changed.

In Sandbox B I do
$ cvs update -r 1.1 FileA
$ cvs update -A FileA

In Sandbox A I then notice the CVS error happens - as described in
https://savannah.nongnu.org/bugs/index.php?23370
I am no longer the editor of FileA.
I then do
$ cvs edit FileB
$ date > FileB # Just to get whatever new content in the file
$ cvs edit FileA # I now try to restore my edit state on FileA
cvs editors now show that I have editor status on both FileA and FileB

.... Here is STATE_1 (I will refer to this spot below)

I can also verify that in $CVSROOT/myproject/..../CVS/fileattr that I
am indeed the editor of each of the files - good!

BUT, if I do
$ cvs unedit FileA
then I get nothing on the command line - I simply loose the file lock
(not mentioned in cvs editors) - and here comes the problem:
The file is STILL locally changed - it is not reverted to the last
check-in state or the truck... whatever.

However if I do
$ cvs unedit FileB
then CVS kindly asks if I want to revert my changes - which I then
accept, and get back to the last version - i.e. drop my local changes.
I will kindly ask you to explain to me, why CVS sees FileA and FileB
differently after I am at STATE_1 (see above).

Best

-- 
Peter Toft <pto@linuxbog.dk>




reply via email to

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