[cvsnt] CVS Rename and Tag problem

Williams, Tim WilliamsTim at PRAIntl.com
Mon Feb 11 15:13:42 GMT 2008


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.


Arthur,

Thank you for the detailed explanation and the time you spent working on
this problem.  Rename is a feature desired by our programmers but it is
not a show-stopper.  We will we proceed with our upgrade plans for
2.5.03 (or 2.5.04 if it becomes production in the next couple of weeks)
and will await EVS before implementing rename in our environment.  

Keep up the great work.

Cheers,

Tim
   

-----Original Message-----
From: Arthur Barrett [mailto:arthur.barrett at march-hare.com] 
Sent: Friday, February 08, 2008 5:01 PM
To: Williams, Tim; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: RE: [cvsnt] CVS Rename and Tag problem

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


 


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