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