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