[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>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- cvs unedit failing with 1.12.13,
Peter Toft <=