[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Rename tracking [was: Presentation for Berlin 10-13 June - "The future of merging with Subversion"]

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 28 May 2010 14:07:15 +0200

On Fri, May 28, 2010 at 12:14:13PM +0100, Julian Foad wrote:
> Ah, you see, I had somehow formed the impression that the phrase is now
> used to mean "Handle renames in such a way that the end result is what
> the users expect, regardless of how it's implemented".
>
> What the users expect has little connection with node-ids and such like,
> and most of the important user-level requirement is summed up by saying
>
> "When merging a rename from a source branch to a target branch,
> Subversion should perform a rename within the target branch,
> not copy something from the source branch."
>
> Certainly a better name for it would be ... better. "Branch-relative
> renames"?

Please consider taking a very good look at how Mercurial handles copies
when merging. I think that could provide some interesting ideas.
For instance, it does apply incoming textual changes to a file to
all local (uncommitted) copies of that file.
The rational behind this is explained here:
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#chap:daily.copy
See "Why should changes follow copies?" and following.
In addition to the book we might want to study the code.
I'm not saying we should copy the concepts 1:1, but we should certainly
look at Mercurial for inspiration on this topic.

Stefan
Received on 2010-05-28 14:08:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.