RE: svn commit: r1414810 - /subversion/trunk/subversion/libsvn_client/merge.c

> -----Original Message-----
> From: cmpilato_at_apache.org [mailto:cmpilato_at_apache.org]
> Sent: woensdag 28 november 2012 17:57
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1414810 -
> /subversion/trunk/subversion/libsvn_client/merge.c
>
> Author: cmpilato
> Date: Wed Nov 28 16:57:01 2012
> New Revision: 1414810
>
> URL: http://svn.apache.org/viewvc?rev=1414810&view=rev
> Log:
> Teach the dry-run merge logic to account for additional flavors of
> ra_serf editor drive ordering violations (*sigh*). Specifically,
> account for situations where the editor drive looks like so:
>
> add_dir("dir1")
> add_dir("dir2")
> add_file("dir1/file")

Are you sure the *editor drive ordering* is like that?

I'm pretty sure the add events are driven on the update report which is identical for all ra layers, while for serf the file and directory modifications may arrive later. It's just that the diff editor only reports the additions after close_file() and close_directory().

The result is the same, but we receive more information on the client, which we might use to avoid these problems...

And this brings us back on the question: should we really drive merges on the diff editor.

The v1 editor works, but it is not the ideal situation. And driving it on a v2 editor will be even harder as there are no clean open events to perform tree conflict tests.

> ...
>
> Formerly, this code would see the add of "dir1/file" and wish to flag
> that as a obstruction because "dir1" wasn't on disk and also wasn't
> the most recent directory added via the merge. ("dir2" was.)
>
> This change causes Subversion to check not just the most recently
> added directory, but all added directories (which were already being
> tracked elsewhere, anyway) before deeming "dir1/file" an obstructed
> merge addition.

        Bert
<snip>
Received on 2012-11-28 18:20:39 CET