RE: svn commit: r1617909 - in /subversion/trunk/subversion: include/svn_wc.h libsvn_wc/conflicts.c libsvn_wc/update_editor.c libsvn_wc/util.c svn/util.c

> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: donderdag 14 augustus 2014 12:56
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1617909 - in /subversion/trunk/subversion:
> include/svn_wc.h libsvn_wc/conflicts.c libsvn_wc/update_editor.c
> libsvn_wc/util.c svn/util.c
>
> Author: stsp
> Date: Thu Aug 14 10:55:42 2014
> New Revision: 1617909
>
> URL: http://svn.apache.org/r1617909
> Log:
> Record the update/switch target revision for missing tree conflicts
> victims in the tree conflict description so the revision can always
> be retrieved during conflict resolution.
>
> For instance, 'svn info' might show:
>
> Tree conflict: local file edit, incoming file delete or move upon update
> Source left: (file) ^/trunk/alpha_at_2
> Source right: (none)
>
> With this change, 'svn info' shows the target revision ("source right')
> of the update/switch which recorded the conflict, even if the node
> was missing:
>
> Tree conflict: local file edit, incoming file delete or move upon update
> Source left: (file) ^/trunk/alpha_at_2
> Source right: (none) @4
>
> There is a slight API change involved which shouldn't affect compatibility.
> The semantics of svn_wc_conflict_version_create2() change such that the
> conflict victim's repos relpath is allowed to be NULL if the node kind
> is 'none'. Previously the API required a canonical path in all cases
> and would ASSERT otherwise, a contract which made it impossible to create
> conflict versions for nodes which don't exist. The provided revision
> number must still be valid in all cases, of course.

In all these cases you still have a really interesing path, to where you tried to switch/update the original path to. If you don't store that you don't know what you tried to switch/update to.

Why don't you store *that path* and the revision?

Note: I don't care about the 'svn' output... Feel free to not show it there, if that might make more sense.

But if I look at the tree conflict information through an API, that path that you tried to switch to is 100% essential information, while a revision is useless information without a repository path. That the node is not there (kind=none) still says me that the node is not there.

"I switched that working copy to r123" doesn't tell me anything, while the information "I switched that working copy to '^/branches/major-QQQ-refactoring_at_r123' tells me everything.

I wish the average user, asking for support knew that...

Even if that path does not exist, I can still chop of one component and use that information with the parent directory's path to perhaps retry the switch at a different revision... Or use it to merge some missing information in.

And a smart tree conflict resolver might even use more tricks than that.... which would be impossible without a path.

        Bert
Received on 2014-08-14 13:14:22 CEST