[cvsnt] UPDATE Does Not Return the Most Recent Revision
bfrost at hcgsoftware.com
Tue Mar 20 18:15:02 GMT 2007
In desperation, I went to the server that runs CVSNT and stopped and
restarted both CVSNT services. This seems to have resolved the issue. I
can now do a regular CVS update and get the latest file revisions. CVSNT is
no longer stuck on an old revision number.
Since I have a quick and easy solution, this issue is no longer a huge
problem. However, CVSNT did somehow get in this state. I don't want this
issue to recur. Is this a known bug that may happen again? Will an upgrade
to CVSNT version 2.5 fix this issue?
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of
Sent: Tuesday, March 20, 2007 9:41 AM
To: cvsnt at cvsnt.org
Subject: [cvsnt] UPDATE Does Not Return the Most Recent Revision
Short Problem Description:
A CVS Update command is no longer returning the most recent revision of
files in the CVS repository.
History and Specs:
I have been using CVSNT every day for a couple of years now without any
problems; version 2.0.58d. I use TortoiseCVS as my client; version 1.8.9.
CVSNT is running on a Win2003 server. Tortoise clients run on WinXP Pro
Last Friday, a CVS update stopped returning the most recent revision of
files in the HEAD branch. Since then, I have tested this multiple times
with the same result. For example, I made a change to an existing file.
Before changes, that file revision number was 1.1. I did a commit which
incremented the revision number to 1.2. A CVS log command shows both
revisions in the repository and shows that 1.2 is the most recent HEAD
revision number. I followed that up with a CVS update command and the file
"rolls back" to revision 1.1 and my changes are no longer in my sandbox. If
I make my changes again, and commit again, the revision number rolls to
something like 18.104.22.168. Further CVS update commands continue to bring me
back to revision 1.1.
Thinking this might be a problem with Tortoise, I stopped using the visual
portion of the client and started typing in the CVS command by hand in a DOS
box. The results were the same. Here is the syntax of my commands:
"C:\Program Files\TortoiseCVS\cvs.exe" update -d -P . (Run from a source
file folder to update the whole folder.) "C:\Program
Files\TortoiseCVS\cvs.exe" log ./TortoiseNotes.txt (Run on a specific file
to get historical information.)
Thinking this had something to do with sticky-ness, tried getting a specific
revision. This brought the correct revision number into my sandbox, but
then left a sticky tag (either date or number; I tried both) on the file.
No further changes could be committed. I then cleared the sticky tag using
CVS update -A and was again "rolled back" to a revision that was not the
latest revision. (i.e. revision 1.1 in my previous example.)
I'm not sure what to do at this point as I can't get CVS to give me the
latest revision of a file using a normal update. This is happening for
every developer on our team and is causing significant problem when our
source tree is updated and local changes are being put in .# files when
"roll backs" happen. Can anyone could shed some light on this problem?
cvsnt mailing list
cvsnt at cvsnt.org
More information about the cvsnt