Thank you for your response! This may demonstrate my question more
clearly:
The script I posted creates an empty trunk and a branch from it, and
then creates dir/file.txt in both trunk and branch separately, and
then merges trunk to branch, resulting in this tree conflict:
% svn st
M .
C dir
> local dir obstruction, incoming dir add upon merge
M dir/file.txt
Summary of conflicts:
Tree conflicts: 1
The path dir/file.txt gains an (empty) svn:mergeinfo property that
remains after resolving and committing the merge:
% svn propget svn:mergeinfo -R
. - /trunk:2-4
dir/file.txt -
% svn resolve --accept=working dir dir/file.txt
Resolved conflicted state of 'dir'
% svn commit -m 'Merge from trunk'
Sending .
Sending dir/file.txt
Committed revision 5.
% svn propget svn:mergeinfo -R
. - /trunk:2-4
dir/file.txt -
Question #1: Once the user has resolved the conflict, why treat
dir/file.txt differently than any other file involved in the merge
from trunk? I have resolved the merge to my satsifaction, and
do not wish to treat subpaths specially.
Question #2: If Subversion were to set dir/file.txt's svn:mergeinfo
property to "/trunk:2-4" after the resolution and prior to the commit,
would this reflect what the user intends, and then cause it to be
elided and disappear?
Interestingly (perhaps?), if I modify dir/file.txt on trunk and merge
that back into branch, the message from Subversion doesn't agree with
what it writes into file.txt's svn:mergeinfo property:
% svn merge ^/trunk
--- Merging r5 through r6 into '.':
U dir/file.txt
--- Recording mergeinfo for merge of r2 through r6 into '.':
U .
--- Recording mergeinfo for merge of r2 through r6 into 'dir/file.txt':
U dir/file.txt
% svn propget -v svn:mergeinfo -R
Properties on '.':
svn:mergeinfo
/trunk:2-6
Properties on 'dir/file.txt':
svn:mergeinfo
/trunk/dir/file.txt:3-6
The merge says it's recording r2 through r6 into dir/file.txt, but
instead it records 3-6. (Trunk didn't change in revision 2, so the
two ranges represent the same set of changes.)
Question #3: If I remove the svn:mergeinfo property on dir/file.txt
prior to committing the first merge, future merges appear to happen
normally and all is happy. Is removing that property going to create
a problem down the road?
If the answer to #3 is "removing the property does not create a
problem, since the user completely resolved all conflicts", then I
would argue that it would be nice if this happened automatically (as
in #2), restoring the pre-1.8 behavior.
Or am I misunderstanding something about the svn:mergeinfo property or
conflict resolution that would explain the need to track dir/file.txt
specially on an ongoing basis?
Thank you for your time.
Pete
On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben <b...@qqmail.nl> wrote:
>
>
>> -----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
>
