Hi Stephan,

Stephan Bergmann wrote:
> On 10/06/09 14:02, Jens-Heiner Rechtien wrote:
>> How should any SCM detect filesystem only renames? This is just asked to
>> much. You have to use "hg rename", of course. Anything else would have
>> to rely on heuristics which might fail, hardly something a SCM can do.
> 
> *Everything* an SCM does when it comes to merging changes (be it to
> individual files or to a complete file hierarchy) relies on heuristics
> and can fail.  The only correct way that could never fail would be to
> declare "there are already changes made to the repository you want to
> commit to, please resolve the mess manually" and not do any automatic
> merging.  (Not the behavior you would expect, though.  Also see
> <http://blogs.sun.com/GullFOSS/entry/mistaking_version_control_for_collaboration>.)

Sure, but there is no need to rely on heuristics where none is needed.
Moving files around is one such case. Doing a "hg rename" or "git mv"
tells the SCM: "These file have a common history and I want changes to
the old file forwarded to the new file". Deleting and adding a file in
another place means "don't bother to forward changes, I don't want them,
these files are no longer related". Both are valid use cases and I think
developers should be required to explicitly state what they want. But,
hey, it's ok to use lazy heuristics as long as no one comes along and
complains when things are forwarded where it shouldn't be and the other
way round.

Back to the original use case which triggered this thread. If you do
rename of a Java class in an IDE then not only the file name will be
changed but also quite a number of places inside the file. Still, the
files are related and forwarding changes should work. How much changes
to a file will the heuristic allow and still consider the files related?
Relying here on heuristics, is asking for trouble, I think. The IDE
should simply issue a SCM rename operation IMHO.

Be explicit where possible.

Regards,
   Heiner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org

Reply via email to