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.
On Thu, 15 Dec 2005 15:09:06 +0100, Kenneth Sørensen <KES at epoke.dk> wrote: >I am aware that tags should be used to keep consistency between files. >We also do that but the consistency is not kept when CVSNT does not >commit what we expect it to do. > >The problem is that the compiled code is deleted or renamed instead >of being replaced with new code. When we do a commit for the module >it is intended that both source code and the compiled code should be >committed. Instead only the source code is committed. This is a problem with your developers not with the CVS tool. If a developer after building his code then deletes the file that is to be committed it is a fault on the developer. CVS will commit only changed files and in this context a changed file is at first a file that *exists* in the sandbox *and* has a local timestamp that differs from the one registered in the CVS/Entries file. In your case there is no file to compare timestamps to since it has been deleted so there is nothing CVSNT can do but disregard it. Then during the commit the files are compared to the server versions and if the local files with modified dates are found to be identical in contents to the ones stored on the server then they are not committed. In WinCvs this is visible as a file that is still red after the commit. A cvs status command on this file will remove the red state by updating the CVS/Entries file with a correct timestamp. >Next we tag the module and now the tag is assigned to the new revision >of the source code but the old revision of the compiled code. The result >is that the old revision of the compiled code is tagged with two different >versions. Of course, the tag operation works on the revisions currently in the sandbox and the deleted file is still at the previous revision (which is the last one since no commit was done). So they all get the same tag value. >All this could be avoided if we could make CVSNT check that all files >are present when it commits. It can't, this is entirely up to the developer. CVS will process all existing files in the folder if only the command cvs commit is given with no file list or process the listed files if the command is cvs commit file1 file2 file3 etc. CVS cannot anticipate what the user wanted to do by the removal of one of the files from the commit command... /Bo (Bo Berglund, developer in Sweden)