> -----Original Message-----
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: woensdag 28 november 2012 17:57
> To: comm...@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>
