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 <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Pete Harlan [mailto:pchpublic88_at_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
>
Received on 2015-03-14 02:45:46 CET