[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 28 May 2010 14:40:10 +0100

Johan Corveleyn wrote:
> On Fri, May 28, 2010 at 2:11 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Fri, May 28, 2010 at 02:07:15PM +0200, Stefan Sperling wrote:
> >> Please consider taking a very good look at how Mercurial handles copies
> >> when merging.
> >
> > And BTW, a rename in Mercurial is also a copy+delete.
> > That's why I think what they are doing is quite relevant to us.
>
> Please don't reduce the issue of "rename tracking" (or whatever you
> want to call it) to merging. It's just as relevant for updating (cf.
> tree conflicts of "local edit, incoming delete" and "local delete,
> incoming edit", etc., which you can just as easily get with a normal
> update). When there is proper rename tracking, I fully expect these
> kinds of tree conflicts to be resolvable automatically (most of the
> time). Whether it's a merge or a regular update.
>
> Unless you consider an update a special kind of merge. However, I
> don't think that's the case in the mind of users (at least in my head,
> as a user, the two are quite different, I use them in totally
> different contexts). That's why I think "Branch-relative renames" is
> not such a good term. It couples the rename issue to
> branching/merging... It's more than that.

Yup, I am certainly not forgetting updates. Thanks for pointing out
that terminology like "branch-relative" may be misleading.

- Julian
Received on 2010-05-28 15:40:48 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.