[evs] Does EVS remove some of CVS limitations?

Eric B. ebenze at hotmail.com
Wed Feb 6 16:50:21 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.

"Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message 
news:if3s1pj63p18.dlg at connectionbrazil.com...
> I'm not sure this is really true. There's the thing with embedded
> references to other files that specify a file name and/or location: HTML,
> XML, CSS and all other web scripting languages, #include directives in C
> and C++ and something similar in pretty much any assembler, VC++ and other
> IDE or editor project files, most word processor and spreadsheet files, 
> and
> so on. A long list... The Java problem is just a special case of this
> problem with textual references to actual file paths. Without propagating
> the renames, only the textual references get propagated, which means they
> stop working. This affects a lot of environments.
> I still don't understand why or when it would make sense to not propagate 
> a
> rename or a move in a C or C++ environment.

I agree entirely with Gerhard.  That being said, I am glad to see that Tony 
agrees as well.

Tony did raise an interesting point, however, about sometimes wanting merge 
in changes from a branch where the file has been moved/renamed, where one is 
only interested in the content change and not interested in modifying the 
file structure / layout.  Although I definitely see that as a possibility / 
eventuality, I would expect that the majority of cases, one would want the 
rename/move to happen during the merge, and only in more rare circumstances, 
encounter the situation to which Tony refers.  Given that, I would think the 
best behaviour would be by default to move/rename during the merge, and have 
a separate switch to disable the feature, if required.


More information about the evs mailing list