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-12 00:55:16 CET