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.
Tim, OK - after much more efforts than I would've liked I've successfully proven that CVSNT is doing the CORRECT thing - it's just not at all obvious. Firstly I'll say that in trying to reproduce your problem I did come across some things that were not working as they should, namely that to commit a rename you currently MUST do it from the SAME directory that you renamed a file in and there must be nothing else in that directory tree to commit. I've fixed that in both 2.5.03 and 2.5.04. A new testing release of 2.5.04 is now available with these changes. Secondly I'll say that there is an aspect of the behaviour I am about to describe that I do NOT like, but I doubt whether fixing it in CVSNT is viable/worthwhile (EVS is really a better solution if you need complex rename functions - the rename functions in CVSNT are designed to handle 'simple' scenarios. So onto your problem, to remind everyone I'll recap. You found that: > This question is in follow up to a post on the TCVS mail list "Disable > Rename in TCVS menus?" where I reported a problem I am having > with file > renaming and tags. Arthur Barrett asked that I post my follow up > observations here. > > Environment: > TCVS 1.10.1 RC10 and CVSNT server 2.5.03 Build 2382. > CVS Server: Windows 2003 Server SP1 Standard Edition > Sandbox: Windows 2003 Server x64 Enterprise Edition > > Problem Summary: > A tag "DataShipment1" is applied to two test files in a folder. Each > file is at revision 1.2. Revisions 1.3 are committed for each file. > One file is renamed from Original2.sas to New2.sas and the changes > committed to the repository. The project is later checked out using > the tag name "DataShipment1." The file in the sandbox is > named New2.sas, > not Original2.sas as it was when the file was tagged. > OK - so 'rename' is really an artefact of 'directory versioning' - however something until today that I did not understand is that 'directory versioning' is not enabled for a directory until a rename occurs within it - and this causes some odd behaviour. In your example - until you rename Original2.sas to New2.sas there is no directory versioning for the directory. So when you tagged revision 1.2 with DataShipment1 that tag was NOT applied to the directory. When you try and checkout tag DataShipment1 after the rename the CVSNT server looks at the directory revisions and neither revision 1.1 (Original2.sas) nor Revision 1.2 (New2.sas) has the tag DataShipment1. So CVSNT server chooses the HEAD revision. It took me a lot of thinking about the problem to realise that this is correct - otherwise if you just checked out no tag (default HEAD) you'd not get the rename. Except of course that for your example the results are extremely unintuitive. You can prove that what I am saying is correct by doing the following after the commit of the rename: cvs -d :sspi:host:/repo rtag -r 1.1 DataShipment1 path/to/modile/.directory_history Now if you checkout path/to/module you will get Original1.sas and Original2.sas as you expected, because revision 1.1 of the directory has the tag DataShipment1. The big question is - is it possible to improve on this logic without making the situation even worse (within the constraints of what'd doable easily in CVSNT - as opposed to EVS where we have a much more effective solution already)? The only 'simple' thing I can think of right now is that if the user HAS specified a tag/branch and that cannot be found in the .directory_history then (and only then) should revision 1.1 be used... I've given this some basic testing and it seems OK so I've put the change into 2.5.04 and created a new testing release which is available now from www.cvsnt.org/wiki/Download (make sure you download the 2.5.04 release, not 2.5.03). Ideally I think it'd be better if either: 1) when a directory is created on the server a .directory_history is automagically created 2) when a .directory_history is created then all the tags/branches of the renamed file should be built into version 1.1 I'm not very keen to do either 1 or 2 above... At first I though that another side effect of all this is that there would be a HUGE difference between tagging or branching with cvs tag and doing the same thing with cvs rtag - however there is specific code to handle this so there is not. Regards, Arthur