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) |
Following up on r1440966, also handle file obstruction handling in the merge
from the file_openened function.
(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
merge_file_deleted): Replace obstruction check with simple baton readout.
(merge_dir_opened): Tweak comment.
(mergeinfo_and_skipped_paths): Expect detailed skip.
(merge_to_sparse_directories): Expect detailed skip.
(tree_conflicts_merge_edit_onto_missing): Expect detailed skip.
(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.
Lack of understanding this issue is preventing us from moving past
1.7; any help would be most appreciated.
On Thu, Mar 12, 2015 at 3:50 PM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
> I verified that this test also fails the same way on the latest
> subversion trunk (1.10.0-dev).
> Pass: 1.6.11
> Pass: 1.7.17
> Fail: 1.8.11
> Fail: 1.10.0-dev
> Is there a reason not to open a bug report?
> On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
>> Thank you for your reply.
>>> the mergeinfo tells that it didn't merge to that node.
>> Once I've resolved the tree conflict, is there a sense in which it
>> didn't merge everything in /trunk into /branches/branch? Marking the
>> tree conflict resolved doesn't remove the svn:mergeinfo property from
>> dir/file.txt, but from my perspective, I've told Subversion how to
>> resolve the merge and therefore want it to consider the two branches
>> fully merged going forward.
>> If the behavior is intentional, what is the recommended way to tell
>> Subversion that I consider the two paths fully merged? And is this
>> difference meant to be introduced in 1.8 vs. 1.7? From what I read it
>> looked like merge semantics weren't intended to change, just some of
>> the client-side bookkeeping.
>> Thank you for your time,
>> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>> I don’t know whether it is a bug or a feature. Storing this value will make
>>> a future merge handle the partial merge that was skipped at first: the
>>> mergeinfo tells that it didn't merge to that node.
>>> There are two ways to remember that: record ‘non inheritable’ info on the
>>> direct parent, and then again on all children that are merged… The untouched
>>> node is then unaffected, but future merges will be slower as more nodes have
>>> specific merge-info. Storing it just on the node that is not merged as you
>>> see here is the other option, which will keep your further merges faster.
>>> In 1.6 we could in general not change the node affected by a tree conflict,
>>> so we always had to choose the slow option. With the central metadata
>>> storage we can do things more efficient… and this allowed fixing a lot of
>>> known issues of previous versions.
>>> Sent from Windows Mail
>>> From: Pete Harlan
>>> Sent: Wednesday, March 11, 2015 11:16 PM
>>> To: 'subversion'
>>> Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
>>> it sets empty svn:mergeinfo properties for files within a
>>> tree-conflicted directory during a merge. The effect is this:
>>> Add empty dir/file.txt to trunk and independently to branch.
>>> Merge trunk to branch; the resulting merge generates:
>>> % svn propget -v svn:mergeinfo -R
>>> Properties on '.':
>>> Properties on 'dir/file.txt':
>>> Expected result is that no svn:mergeinfo property would appear on
>>> dir/file.txt. Is this a bug? A known bug?
>>> Script to reproduce (run as "script.sh /path/to/svn"):
>>> # Reproduce an issue in Subversion 1.8.11 where files in a tree
>>> # conflict can have svn:mergeinfo properties added to them during a
>>> # merge.
>>> set -e
>>> if [ $# != 1 ]; then
>>> echo "usage: $0 <path to svn>"
>>> SVNADMIN="$(dirname $SVN)/svnadmin"
>>> createAndCommitSubdirWithFile ()
>>> mkdir dir
>>> touch dir/file.txt
>>> $SVN add dir
>>> $SVN commit -m "$1"
>>> $SVN update # Update . to committed rev
>>> # Create the repo and enter it.
>>> $SVNADMIN create $SERVER_DIR
>>> $SVN checkout $SERVER_URL $CLIENT_DIR
>>> cd $CLIENT_DIR
>>> # Create the trunk/branches structure
>>> mkdir trunk
>>> mkdir branches
>>> $SVN add trunk branches
>>> $SVN commit -m 'Create initial structure'
>>> # Make a branch from the trunk.
>>> $SVN copy ^/trunk ^/branches/branch -m 'Create branch from trunk'
>>> # Commit a subdir with a file in it in the trunk and commit it.
>>> $SVN switch --ignore-ancestry ^/trunk
>>> createAndCommitSubdirWithFile 'Committed on trunk'
>>> # Commit a subdir with a file in it in the branch and commit it.
>>> $SVN switch ^/branches/branch
>>> createAndCommitSubdirWithFile 'Committed on branch'
>>> # Merge the trunk and display any svn:mergeinfo properties.
>>> # (Remove --non-interactive if testing svn prior to 1.7)
>>> $SVN merge --non-interactive ^/trunk || true
>>> $SVN propget svn:mergeinfo -R . >actual.out
>>> echo '. - /trunk:2-4' >expected.out
>>> $SVN --version | head -1
>>> if diff -q actual.out expected.out; then
>>> echo Success
>>> echo 'Test failed!'
>>> echo 'Expected output:'
>>> cat expected.out
>>> echo 'Actual output:'
>>> cat actual.out
>>> exit 1
Received on 2015-03-13 23:18:11 CET