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, > 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 template). 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 boilerplate. 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 ;) Regards, Arthur