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. Eric