> -----Original Message-----
> From: Pete Harlan [mailto:pchpubli...@gmail.com]
> Sent: vrijdag 13 maart 2015 23:18
> To: Bert Huijben
> Cc: subversion
> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in
> subdirs
>
> Hi,
>
> I narrowed down the change to this commit, in version 1.8.0-dev:
>
> ------------------------------------------------------------------------
> r1441043 | rhuijben | 2013-01-31 08:20:25 -0800 (Thu, 31 Jan 2013) |
> 30 lines
>
> Following up on r1440966, also handle file obstruction handling in the merge
> from the file_openened function.
>
> * subversion/libsvn_client/merge.c
> (merge_file_baton_t): Add fields to store conflicts and skips.
> (mark_dir_edited): Add comment.
> (mark_file_edited): Handle skips and tree conflicts on files.
>
> (merge_file_opened): Handle obstruction handling for changes, adds, deletes
> and persist the result in the baton. Or notify if we know the result for
> delete/add.
>
> (merge_file_changed,
> merge_file_added,
> merge_file_deleted): Replace obstruction check with simple baton readout.
>
> (merge_dir_opened): Tweak comment.
>
> * subversion/tests/cmdline/merge_authz_tests.py
> (mergeinfo_and_skipped_paths): Expect detailed skip.
>
> * subversion/tests/cmdline/merge_tests.py
> (merge_to_sparse_directories): Expect detailed skip.
>
> * subversion/tests/cmdline/merge_tree_conflict_tests.py
> (tree_conflicts_merge_edit_onto_missing): Expect detailed skip.
>
> * subversion/tests/cmdline/tree_conflict_tests.py
> (at_directory_external): Remove Wimp marker (added in r1440966)
>
> I don't know Subversion internals so I haven't dug in further than
> this. Is there a way that I should be resolving the tree conflict
> that would tell Subversion that I don't want the subdirectory to have
> a detached svn:mergeinfo? I'm using "svn resolve --accept=working
> <path>" but that leaves the property in place on the file within path.
That just removes the marker that there was a conflict... It doesn't resolve
the actual conflict.
And in your mails I haven't found a clear description either...
The change you quote here is that something is skipped, because it was
obstructed. (Unversioned obstruction? Other merge? Something else?)
Subversion doesn't know if that skip was intentional or needs further handling
from you as the user. That is why it marks the tree conflict.
In some cases you might want to perform a followup merge to complete the merge
where it stopped at the obstruction. That might just be the same operation as
before, because it will continue where it had to stop the last time. That is
why it records this mergeinfo... It hasn't merged this part of the tree.
In other cases you might want to perform a record only merge, to record that
something wass merged... if the thing to be merged is nothing at all.
Subversion found an obstruction... Something in the way of what it expected to
be changing.
* Why?
* How should the merge continue?
* What should the user do manually to resolve the obstruction
* What could Subversion have done automatically to resolve the obstruction
* How should this be recorded in Subversion.
That is what the tree conflict asks you...
And to help you further I need at least more information than I have now.
Just creating an issue in our issue tracker is not going to help here...
It will just delay your question until eventually another developer will be
asking these same questions. Probably only in a few years when you forgot the
answers.
That is why we ask to only create issues after creating a full bug report and
in a way that eventually it can be resolved. The issue tracker is just for
remembering issues/todos, not a way to escalate a problem. Recording it there
is not a step towards resolving a problem.
I currently have absolutely no idea where to look at to fix 'your issue', and
I'm pretty sure none of the other Subversion developers has a clue either.
This all starts by 'what kind of obstruction' is there... Is there an
obstruction or is the fact that Subversion detects the obstruction a bug?
An existing tree conflict that hasn't been resolved is certainly an
obstruction... That is why merges are interrupted to resolve the conflicts
before continuing. (And the intermediate state of the merge is recorded in the
mergeinfo properties)
Bert
