[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 28 May 2010 14:36:21 -0400

Stefan Sperling 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.

As previously stated, I really don't see the copy+delete implementation
detail as an insurmountable problem for Subversion, and this has been my
stance for a long while now. I'd like to see Subversion apply changes
during update/merge to all local copies of a file targeted for tweaks by
that operation. I'd like to see Subversion's client side *not* lose the
information that ties the delete and copy together. I'd like to the see the
Subversion server behave intelligently when renames are committed, detecting
conflicts that would otherwise be allowed (the double-delete scnenario,
etc.) I'd like to see our merge operations be smarter about rename
detection and transmission[1]. I'd like ... well, I'd like a pony.

-- C-Mike

[1] When I have to manually deal with renames in merge scenarios, I follow a
routine that seems to generally work out well for me. Consider a merge of a
range like this:

r280 | cmpilato | 2010-05-28 23:13:00 -0400 (Fri, 28 May 2010) | 1 line
Changed paths:
   M /trunk/some-dir/file.txt
r279 | cmpilato | 2010-05-27 23:19:04 -0400 (Thu, 27 May 2010) | 1 line
Changed paths:
   A /trunk/some-dir (from /trunk/dir:278)
   D /trunk/dir
r278 | cmpilato | 2010-05-27 23:13:50 -0400 (Thu, 27 May 2010) | 1 line
Changed paths:
   M /trunk/dir/file.txt
r277 | cmpilato | 2010-05-21 15:32:09 -0400 (Fri, 21 May 2010) | 1 line
Changed paths:
   M /trunk/dir/bloo.txt

I would manually merge -r276:278. Then I'd perform the same rename from
r279 in my working copy. And then I'd merge r280. Why can't Subversion do
this for me? I think we can get to the point where it can.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-05-28 20:37:08 CEST

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