[cvsnt] UPDATE Does Not Return the Most Recent Revision

Brandon Frost bfrost at hcgsoftware.com
Tue Mar 20 16:41:27 GMT 2007


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


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
development machines.

Detail Scenario:
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 1.1.2.1.  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?

Thank you.
 
Brandon Frost



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook