[evs] Does EVS remove some of CVS limitations?

Arthur Barrett arthur.barrett at march-hare.com
Wed Feb 6 21:52:15 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.


> Basically, that would require that the change (in Arthur's "safe use"
> policy that would be a change marked with a bug number) is separated into
> two changes: the content changes that are not affected by the rename on 
> one
> bug number, and then the rename and the content changes that depend on the
> rename on another bug number. Then you can merge the former without the
> latter. Otherwise, if you merge all of the change's content without the
> rename, your include directives or links will be wrong.

Yes exacly.

In practice I maintain that files in web sites and C 'header' files are 
rarely renamed - the rename 'problem' is highlighted primarily by 'Java' 
progammers usage.  eg: in the CVSNT project we've never renamed a C 'header' 
file, and in fact in all the software projects and web site development I've 
been involved with over 15 years I've never renamed a file or seen another 
developer rename a file except for in the CVSNT project where the .c files 
became .cpp files...

Something which EVSr1 doesn't do but in a future release I'd like to see it 
do is track deriratives.  Ie: if I copy src/history.cpp and create a new 
file called src/audit.cpp then that'd be useful to know as part of the 
history of both files - that history.cpp has the deriratives audit.cpp and 
graph.cpp and that audit.cpp was derived from history.cpp (or perhaps a 
better example is if I create the word document spec.doc from spec.dot 

Again I've never seen a business analyse rename func-spec-A7B001.doc to 
func-spec-screen-A7B001.doc, the filenames are kinda treated as sacred since 
they are referred to in gazillions of places, but I have seen plenty of 
business analysts copy spec A7B001 to create A7B002 and then leave some 
boilerplate text there that doesn't really apply to 002 - if the developer 
could 'see' that the 002 spec was indeed derived from the 001 spec and that 
the boilerplate wasn't touched then they have cause to go back to the BA and 
have them confirm the spec for 002 needs that function described in the 

I agree that SCM systems (including EVS) now have to handle rename well 
(including in a merge), but I maintain the argument that if it wasn't for 
Java we'd be concentrating on more productive features and ignoring the 
rename issue as one that is purely academic.

To illustrate my point: you rename product.html to product.asp, I then go to 
your web site with a saved link that refers to product.html - I get 'page 
not found' - I conspicuously do NOT get a message that says 'page renamed'. 
What all web developers are familiar with is needing to create a 'new' 
product.html that 'redirects' the user to product.asp.  In fact what has 
happened is that product.html has been 'copied' to product.asp and 
product.asp is derived from product.html.  The product.html is later 
modified to be a 'simple' redirect page.

Conversely I do think that no matter what a files name is, or where it is 
moved to it is still the same file, and that's something I'd also like to 
see better support for in SCM/CM tools - so if I create spec.doc and then 
e-mail it to you Gerhard then you modify it then pop it on a CD and send it 
by post to Tony and he get's it and puts it on his iPhone and makes a few 
mods and then sends it as an IM attachment to me the ideal SCM would know 
it's the same file  In fact the ideal SCM will have tracked each of those 
changes and the manner of the change and the 'location' of the change and 
the means of communication.

I suppose a good 'first step' is getting rename to work well wih Java ;)



More information about the evs mailing list