[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 28 May 2010 15:33:20 +0200

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.

Cheers,

-- 
Johan
Received on 2010-05-28 15:33:55 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.