On 11.07.2012 13:43, Johan Corveleyn wrote:
> On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> ...
>> I just want to say: I'm not at all demanding we break backward
>> compatibility. Sorry if it sounded like it. I'm just saying that we're
>> proposing to change the behaviour of the plain merge command, and in doing
>> that we need to work out what the details of the new behaviour will be, and
>> this thread is helping us to do just that. I ended up with a bias towards
>> trying to move toward a more rename-friendly approach, but I recognise we
>> can't get there yet so the "follow each node's own ancestry" idea is just an
>> idea for the future. We need a simpler approach for now.
> I intended to join the discussion when this thread first started, but
> never got around to it...
>
> I just wanted to add: it seems to me that for a rename-friendly merge
> (rename-friendly accross the entire tree that's being merged), we at
> least need to first tackle the problem of handling server-side
> renames/moves for 'update' (as 'update' can be seen as a simple
> merge-like case). If and when that problem is solved, and we get a
> clear understanding of the desired behavior involved, and get more
> experience with that, only then can we start thinking about the more
> complex situation of 'merge'.
That is correct. Essentially, not only does the server have to know
about and correctly record renames; the rename operations in the update
(or merge) editor drive need to happen in the correct order so that they
can be reflected in the working copy filesystem.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-07-11 15:12:59 CEST