You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2017/01/25 14:41:03 UTC
svn commit: r1780191 - /subversion/site/publish/docs/release-notes/1.10.html
Author: stsp
Date: Wed Jan 25 14:41:03 2017
New Revision: 1780191
URL: http://svn.apache.org/viewvc?rev=1780191&view=rev
Log:
* release-notes/1.10.html: Add a section about the new conflict resolver.
Modified:
subversion/site/publish/docs/release-notes/1.10.html
Modified: subversion/site/publish/docs/release-notes/1.10.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.10.html?rev=1780191&r1=1780190&r2=1780191&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.10.html (original)
+++ subversion/site/publish/docs/release-notes/1.10.html Wed Jan 25 14:41:03 2017
@@ -103,12 +103,12 @@ and what impact these changes may have.<
<th>Notes</th></tr>
<tr>
<td>
- <a href="#conflict-resolver">New conflict resolver</a>
+ <a href="#conflict-resolver">New interactive conflict resolver</a>
</td>
<td>1.10</td>
<td>any</td>
<td>any</td>
- <td></td></tr>
+ <td>Use SVN 1.8 and above clients only for best results.</td></tr>
</table>
</div> <!-- new-feature-compatibility-table -->
@@ -174,12 +174,180 @@ users. We'll cover those in this sectio
</h2>
<div class="h3" id="conflict-resolver">
-<h3>New conflict resolver
+<h3>New interactive conflict resolver
<a class="sectionlink" href="#conflict-resolver"
title="Link to this section">¶</a>
</h3>
-<p>Subversion 1.10 features a new conflict resolver.</p>
+<p>Subversion 1.10 provides much better interactive resolution of tree conflicts
+ than previous releases.</p>
+
+<p>Interactive conflict resolution has been completely redesigned and rewritten.
+ This new conflict resolver supersedes the first implementation introduced
+ in Subversion 1.5.</p>
+
+<p>The new conflict resolver searches repository history for structural changes
+ (additions, deletions, copies, and moves) which conflict with local changes
+ in the working copy and cause tree conflicts. Tree conflicts are now described
+ in detail, including revision numbers and names of authors of conflicting changes.
+ In previous versions of Subversion, the task of finding such information was
+ left to the user. Automating this task is a huge usability improvement.</p>
+
+<p>The new conflict resolver is able to detect moves and renames in repository
+ history, and take them into account while modifying the local working copy.
+ This makes seamless merging between branches possible even if one or both
+ branches rename files or directories. For best results, all SVN clients
+ committing to the repository should be at version 1.8 or higher.</p>
+
+<p>The conflict resolver user interface remains largely unchanged. Like in
+ previous releases, the resolver will be started automatically if an update,
+ merge, or switch operation ends with unresolved conflicts. It can also be
+ started on demand by running the <tt>svn resolve</tt> command. For more
+ information, run <tt>svn help resolve</tt> after installing Subversion 1.10.</p>
+
+<p>In some situations, resolving one tree conflict will cause new other tree conflicts
+ to appear. The <tt>svn resolve</tt> command will keep iterating over such conflicts
+ until none are left, or until the user decides to quit the operation.</p>
+
+<p>The new conflict resolver offers a variety of automated tree conflict resolution
+ options which users can choose from. Not all kinds of tree conflicts can yet be
+ described and resolved. The options available in Subversion 1.10.0 are listed below.</p>
+
+<p>Future releases of Subversion will continue to provide enhancements for the new
+ conflict resolver. We expect to add coverage of additional conflict cases and add
+ additional resolution options even in patch releases (i.e. in 1.10.1, 1.10.2, etc.).</p>
+
+<table border="1">
+ <tr>
+ <th>operation</th>
+ <th>incoming change</th>
+ <th>local change</th>
+ <th>kinds of versioned items</th>
+ <th>resolution options</th>
+ </tr>
+ <tr>
+ <td>update, switch</td>
+ <td><ul>
+ <li>edit a file</li>
+ <li>any change inside a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>move</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming file and local file</li>
+ <li>incoming directory and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>update move destination<br>
+ (using this option is recommended)</li>
+ <li>break move and update any moved away children<br>
+ (updates items moved outside of the moved directory)</li>
+ </ul></td>
+ </tr>
+ <tr>
+ <td>merge</td>
+ <td><ul>
+ <li>edit a file</li>
+ <li>any change inside a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>move</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming file and local file</li>
+ <li>incoming directory and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>apply change to move destination<br>
+ </ul></td>
+ </tr>
+ <tr>
+ <td>update, merge, switch</td>
+ <td><ul>
+ <li>delete an item</li>
+ </ul></td>
+ <td><ul>
+ <li>edit a file</li>
+ <li>any change inside a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming nothing and local file</li>
+ <li>incoming nothing and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>ignore deletion<br>
+ <li>accept deletion<br>
+ </ul></td>
+ </tr>
+ <tr>
+ <td>update, switch</td>
+ <td><ul>
+ <li>add a file</li>
+ <li>add a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>add</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming file and local file</li>
+ <li>incoming directory and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>ignore incoming addition<br>
+ (discards the incoming change)</li>
+ <li>merge incoming and local item</li>
+ </ul></td>
+ </tr>
+ <tr>
+ <td>merge</td>
+ <td><ul>
+ <li>add a file</li>
+ <li>add a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>add</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming file and local file</li>
+ <li>incoming directory and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>ignore incoming addition<br>
+ (discards the incoming change)</li>
+ <li>merge incoming and local item<br>
+ (item's log history will trace back on local branch)</li>
+ <li>replace local item with incoming item, then merge them<br>
+ (item's log history will trace back to other branch)</li>
+ </ul></td>
+ </tr>
+ <tr>
+ <td>update, merge, switch</td>
+ <td><ul>
+ <li>move a file</li>
+ <li>move a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>edit a file</li>
+ <li>any change inside a directory</li>
+ </ul></td>
+ <td><ul>
+ <li>incoming file and local file</li>
+ <li>incoming directory and local directory</li>
+ </ul></td>
+ <td><ul>
+ <li>move and merge<br>
+ (applies the same move locally and merges items)</li>
+ </ul></td>
+ </tr>
+</table>
+
+<p>Note that, in particular, most cases where files clash with directories
+ are not yet handled.</p>
+
+<p>At present, the conflict resolver can be used interactively or called
+ from Subversion's client API. There is no support for non-interactive
+ conflict resolution with the <tt>svn</tt> command yet.
</div> <!-- conflict-resolver -->
Re: svn commit: r1780191 -
/subversion/site/publish/docs/release-notes/1.10.html
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 08, 2017 at 01:59:24AM +0100, Johan Corveleyn wrote:
> On Tue, Feb 7, 2017 at 1:11 PM, Stefan Sperling <st...@elego.de> wrote:
> > On Tue, Feb 07, 2017 at 12:40:10PM +0100, Johan Corveleyn wrote:
> >> BTW: why no "deleted an item" for local change (can't look at the code
> >> / resolver options right now myself, so just wondering ...)?
> >
> > I've just added one case where the resolver has special-purpose code for
> > that (code which already existed in 1.9): https://svn.apache.org/r1781991
> > This case is in the first row (incoming edit vs local delete/move),
> > and updates children which were moved out of the directory before the
> > directory itself was deleted.
> >
> > Apart from 'accept current working copy state' (aka postpone), there
> > is no other case where the resolver code looks for a local change
> > with reason code svn_wc_conflict_reason_deleted.
> > It is quite possible that the resolver is missing a lot of other cases
> > where this condition would apply!
>
> Okay, I did some table-reshuffling attempt in r1782093. Feel free to
> change it further or to revert back if you think it's worse than
> before.
Thanks! Looks good to me :)
> Concerning 'delete a directory', I don't fully understand what you
> meant, so I left that resolution option with '...'. What I'd expect to
> be possible, if I had locally deleted a directory or a file, is to
> ignore any incoming change, and just accept the working copy situation
> (i.e. deleted) -- not postponing, but just accepting the working copy
> situation and mark it as resolved. The other interesting option would
> probably be: revert my local deletion and apply the incoming change.
I mixed something up: 'accept current working copy state' maps to 'mark
resolved', not 'postpone'. So you could use the 'accept current working
copy state' option in this case and it should do what you expect.
Re: svn commit: r1780191 - /subversion/site/publish/docs/release-notes/1.10.html
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 7, 2017 at 1:11 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Feb 07, 2017 at 12:40:10PM +0100, Johan Corveleyn wrote:
>> BTW: why no "deleted an item" for local change (can't look at the code
>> / resolver options right now myself, so just wondering ...)?
>
> I've just added one case where the resolver has special-purpose code for
> that (code which already existed in 1.9): https://svn.apache.org/r1781991
> This case is in the first row (incoming edit vs local delete/move),
> and updates children which were moved out of the directory before the
> directory itself was deleted.
>
> Apart from 'accept current working copy state' (aka postpone), there
> is no other case where the resolver code looks for a local change
> with reason code svn_wc_conflict_reason_deleted.
> It is quite possible that the resolver is missing a lot of other cases
> where this condition would apply!
Okay, I did some table-reshuffling attempt in r1782093. Feel free to
change it further or to revert back if you think it's worse than
before.
I attempted to eliminate the 'operation' column as well, because there
is overlap between the resolution options of 'update, switch' and
'merge'. But then I ended up "annotating" somehow the resolution
options that were specific to an operation, which got a bit confusing
(especially because some resolution options already use the term
'merge' in another meaning as the 'merge' operation). So for now I
thought it best to leave the 'operation' column in there (unless the
options start looking more and more the same).
Concerning 'delete a directory', I don't fully understand what you
meant, so I left that resolution option with '...'. What I'd expect to
be possible, if I had locally deleted a directory or a file, is to
ignore any incoming change, and just accept the working copy situation
(i.e. deleted) -- not postponing, but just accepting the working copy
situation and mark it as resolved. The other interesting option would
probably be: revert my local deletion and apply the incoming change.
--
Johan
Re: svn commit: r1780191 -
/subversion/site/publish/docs/release-notes/1.10.html
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 07, 2017 at 12:40:10PM +0100, Johan Corveleyn wrote:
> BTW: why no "deleted an item" for local change (can't look at the code
> / resolver options right now myself, so just wondering ...)?
I've just added one case where the resolver has special-purpose code for
that (code which already existed in 1.9): https://svn.apache.org/r1781991
This case is in the first row (incoming edit vs local delete/move),
and updates children which were moved out of the directory before the
directory itself was deleted.
Apart from 'accept current working copy state' (aka postpone), there
is no other case where the resolver code looks for a local change
with reason code svn_wc_conflict_reason_deleted.
It is quite possible that the resolver is missing a lot of other cases
where this condition would apply!
Re: svn commit: r1780191 - /subversion/site/publish/docs/release-notes/1.10.html
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 7, 2017 at 12:36 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Feb 07, 2017 at 12:25:09PM +0100, Johan Corveleyn wrote:
>> I've been looking at the table in the release notes (in my browser,
>> not the textual diff, but replying on this commit to have some context
>> -- the "kinds of versioned items" column is already gone btw).
>>
>> I think it would be easier to understand for users if we changed the
>> order of the columns, to describe it like a user encountering the tree
>> conflict would experience it (at least, the way I experience it :-),
>> which is:
>>
>> 1) What's my local situation (local change)
>> 2) What operation did I do (operation)
>> 3) What's the incoming change
>> 4) Resolution options
>>
>> The grouping between some things would then change as well.
>>
>> So that would be:
>>
>> <tr>
>> <th>local change</th>
>> <th>operation</th>
>> <th>incoming change</th>
>> <th>resolution options</th>
>> </tr>
>>
>> In the first column there would be 4 possibilities right now, if we
>> shuffle the table around: "move an item", "add an item", "any change
>> inside a directory", "edit file" (or maybe these should be set in past
>> tense "edited file", "moved item", ... , because the user did them
>> already?). BTW: this makes me wonder, why no "deleted an item" for
>> local change?
>>
>> I'm willing to do this shuffling if we agree, and if noone else does
>> it first :-).
>
> Yes, this makes sense.
> Please just go ahead. I'd be happy to see you make any edits you wish to make.
> Let me know when you're done and I'll take a look at the result.
>
> The visual representation of this table is important, so having something
> to look at is better than discussing abstract ideas, I think :)
Ok, I'll give it a go tonight.
BTW: why no "deleted an item" for local change (can't look at the code
/ resolver options right now myself, so just wondering ...)?
--
Johan
Re: svn commit: r1780191 -
/subversion/site/publish/docs/release-notes/1.10.html
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 07, 2017 at 12:25:09PM +0100, Johan Corveleyn wrote:
> I've been looking at the table in the release notes (in my browser,
> not the textual diff, but replying on this commit to have some context
> -- the "kinds of versioned items" column is already gone btw).
>
> I think it would be easier to understand for users if we changed the
> order of the columns, to describe it like a user encountering the tree
> conflict would experience it (at least, the way I experience it :-),
> which is:
>
> 1) What's my local situation (local change)
> 2) What operation did I do (operation)
> 3) What's the incoming change
> 4) Resolution options
>
> The grouping between some things would then change as well.
>
> So that would be:
>
> <tr>
> <th>local change</th>
> <th>operation</th>
> <th>incoming change</th>
> <th>resolution options</th>
> </tr>
>
> In the first column there would be 4 possibilities right now, if we
> shuffle the table around: "move an item", "add an item", "any change
> inside a directory", "edit file" (or maybe these should be set in past
> tense "edited file", "moved item", ... , because the user did them
> already?). BTW: this makes me wonder, why no "deleted an item" for
> local change?
>
> I'm willing to do this shuffling if we agree, and if noone else does
> it first :-).
Yes, this makes sense.
Please just go ahead. I'd be happy to see you make any edits you wish to make.
Let me know when you're done and I'll take a look at the result.
The visual representation of this table is important, so having something
to look at is better than discussing abstract ideas, I think :)
Re: svn commit: r1780191 - /subversion/site/publish/docs/release-notes/1.10.html
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jan 25, 2017 at 3:41 PM, <st...@apache.org> wrote:
> Author: stsp
> Date: Wed Jan 25 14:41:03 2017
> New Revision: 1780191
>
> URL: http://svn.apache.org/viewvc?rev=1780191&view=rev
> Log:
> * release-notes/1.10.html: Add a section about the new conflict resolver.
...
> +<table border="1">
> + <tr>
> + <th>operation</th>
> + <th>incoming change</th>
> + <th>local change</th>
> + <th>kinds of versioned items</th>
> + <th>resolution options</th>
> + </tr>
I've been looking at the table in the release notes (in my browser,
not the textual diff, but replying on this commit to have some context
-- the "kinds of versioned items" column is already gone btw).
I think it would be easier to understand for users if we changed the
order of the columns, to describe it like a user encountering the tree
conflict would experience it (at least, the way I experience it :-),
which is:
1) What's my local situation (local change)
2) What operation did I do (operation)
3) What's the incoming change
4) Resolution options
The grouping between some things would then change as well.
So that would be:
<tr>
<th>local change</th>
<th>operation</th>
<th>incoming change</th>
<th>resolution options</th>
</tr>
In the first column there would be 4 possibilities right now, if we
shuffle the table around: "move an item", "add an item", "any change
inside a directory", "edit file" (or maybe these should be set in past
tense "edited file", "moved item", ... , because the user did them
already?). BTW: this makes me wonder, why no "deleted an item" for
local change?
I'm willing to do this shuffling if we agree, and if noone else does
it first :-).
--
Johan