1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

Hi,

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:

Layout:

/trunk
/branches/branch

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 '.':
  svn:mergeinfo
    /trunk:2-4
Properties on 'dir/file.txt':
  svn:mergeinfo

%

Expected result is that no svn:mergeinfo property would appear on
dir/file.txt.  Is this a bug?  A known bug?

Thanks,
Pete

Script to reproduce (run as "script.sh /path/to/svn"):

#!/bin/bash
#
# 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

SERVER_DIR=server
CLIENT_DIR=client

if [ $# != 1 ]; then
    echo "usage: $0 <path to svn>"
    exit
fi

SVN=$1
SVNADMIN="$(dirname $SVN)/svnadmin"

SERVER_URL="file:///$PWD/$SERVER_DIR"

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
else
    echo 'Test failed!'
    echo 'Expected output:'
    cat expected.out
    echo 'Actual output:'
    cat actual.out
    exit 1
fi

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Daniel Shahaf <d....@daniel.shahaf.name>]

Pete Harlan wrote on Mon, Mar 30, 2015 at 08:40:46 -0700:
> On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
> >> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> >> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pc...@gmail.com> wrote:
> >> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
> >> >>> Is it accurate then to say that Subversion may generate explicit
> >> >>> mergeinfo whenever it decides that there is something useful to record
> >> >>> about the set of revisions that contributed to a given node, and that
> >> >>> svn:mergeinfo properties may appear in subnodes as part of normal
> >> >>> Subversion merging bookkeeping, and this doesn't imply lack of a full
> >> >>> root->root merge or other user shenanigans?
> >> >>>
> >> >>> I appreciate your time on this.
> >> >>
> >> >> Hi,
> >> >>
> >> >> Is that an accurate description?  I'm not trying to file a bug report
> >> >> anymore, I'm just looking to understand the intent of this property so
> >> >> we can know what to expect when moving forward from 1.7.
> >> >>
> >> >> Thanks for your help,
> >> >>
> >> >
> >> > Yes, I think it's possible that svn records mergeinfo on subnodes
> >> > (directories or files), even if there is nothing to do there. It
> >> > happens for instance when that subnode already has some explicit
> >> > mergeinfo (explicit, as opposed to inherited), because of some
> >> > previous merge. As soon as a node has explicit mergeinfo, that
> >> > explicit mergeinfo needs to be updated on every merge to the root of
> >> > the branch.
> >> >
> >> > I'm trying to explain from memory here, possibly not entirely
> >> > accurate. I think you should really start by reading this article [1]
> >> > describing the merge tracking introduced in 1.5 (it has undergone
> >> > changes and many bugfixes since then, but the underlying principles
> >> > are still the same). It explains nicely some important terms such as
> >> > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
> >> > etc..
> >> >
> >> > Also, some changes were made in 1.7 to reduce the amount of
> >> > unnecessary subtree-mergeinfo changes [2].
> >> >
> >> > [1] https://www.open.collab.net/community/subversion/articles/merge-info.html
> >> > [2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
> >> >
> >> > --
> >> > Johan
> >>
> >> Thank you.  I don't mean updates to explicit mergeinfo, which I
> >> understand from 1.7 and prior, and I have read the docs on mergeinfo
> >> handling.  In 1.8 and later I've started to see explicit svn:mergeinfo
> >> properties appearing on subtrees outside the context of user-initiated
> >> non-root merges and am trying to follow the circumstances in which
> >> they occur and whether I should stop being concerned about them.
> >>
> >> The earlier parts of this thread [1], where I was believing the new
> >> mergeinfo properties to be inadvertent (i.e., bugs) detail my
> >> confusion.  I have stopped trying to tell the Subversion authors what
> >> I thought they meant to do :), and am now trying to get a solid
> >> understanding going forward.
> >>
> >> I (and others) had been inferring non-root merges when seeing explicit
> >> subtree mergeinfo (an inference informed by the articles that you
> >> cite), and believe on the basis of this thread that I have to stop
> >> doing that if I want to use 1.8 or newer.  Because of the necessity to
> >> explain the rules to our developers, I was hoping for further
> >> clarification of those rules here.
> >>
> >
> > I think it's fairly accurate to say that a merge will only create/update
> > svn:mergeinfo on:
> >
> > 1. The merge target (i.e., usually the root of some branch).
> >
> > 2. Descendants of #1 that already have svn:mergeinfo properties.
> >
> > 3. Descendants of #1 that have a child or sibling that is switched or
> > excluded by authz (called "server-excluded" in the code) or excluded by
> > depth setting or not the same revision (in the 'svn info | grep
> > ^Revision:' sense) as its parent.
> >
> > Put another way, if you have a uniform-revision working copy with no
> > subtrees that are (switched or excluded-by-depth or server-excluded),
> > then svn:mergeinfo changes will only occur on the target root and on
> > files/dirs that already had svn:mergeinfo properties before the merge
> > started.
> >
> > Daniel
> >
> >> [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
> >>
> >> Thanks,
> >>
> >> --Pete
> 
> That was my understanding also, but this isn't the behavior in 1.8
> (see this thread).  I reported the change as a bug, but Subversion's
> maintainers say that the new behavior is normal (which is what this
> thread has been about).  Hence my attempt to clarify what the rules
> are, or whether I need to stop caring about explicit mergeinfo (or
> stay with 1.7).

Will Subversion ever behave differently if the explicit svn:mergeinfo is
removed before the merge is committed, compared to how it would behave
if the explicit svn:mergeinfo were retained?

In my opinion, if the answer is "No", then having that explicit
svn:mergeinfo is a bug.  Possibly a "wrong data is recorded" bug, but at
least a usability bug, due to how existence of explicit svn:mergeinfo
spams 'svn log -qv' of every merge commit down the road.

In the case of your script upthread, even if I add a 'svn merge
^/trunk/dir dir', I get mergeinfo of
	branch - trunk:2-4
	branch/dir - trunk/dir:4
and now the question is, effectively, "Is mergeinfo of trunk/dir:2-3 on
branch/dir a no-op for future merges".  (Keeping in mind that trunk/dir
didn't even exist at r2.)

Unfortunately, I don't know the answer to that.

Daniel

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
>> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pc...@gmail.com> wrote:
>> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
>> >>> Is it accurate then to say that Subversion may generate explicit
>> >>> mergeinfo whenever it decides that there is something useful to record
>> >>> about the set of revisions that contributed to a given node, and that
>> >>> svn:mergeinfo properties may appear in subnodes as part of normal
>> >>> Subversion merging bookkeeping, and this doesn't imply lack of a full
>> >>> root->root merge or other user shenanigans?
>> >>>
>> >>> I appreciate your time on this.
>> >>
>> >> Hi,
>> >>
>> >> Is that an accurate description?  I'm not trying to file a bug report
>> >> anymore, I'm just looking to understand the intent of this property so
>> >> we can know what to expect when moving forward from 1.7.
>> >>
>> >> Thanks for your help,
>> >>
>> >
>> > Yes, I think it's possible that svn records mergeinfo on subnodes
>> > (directories or files), even if there is nothing to do there. It
>> > happens for instance when that subnode already has some explicit
>> > mergeinfo (explicit, as opposed to inherited), because of some
>> > previous merge. As soon as a node has explicit mergeinfo, that
>> > explicit mergeinfo needs to be updated on every merge to the root of
>> > the branch.
>> >
>> > I'm trying to explain from memory here, possibly not entirely
>> > accurate. I think you should really start by reading this article [1]
>> > describing the merge tracking introduced in 1.5 (it has undergone
>> > changes and many bugfixes since then, but the underlying principles
>> > are still the same). It explains nicely some important terms such as
>> > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
>> > etc..
>> >
>> > Also, some changes were made in 1.7 to reduce the amount of
>> > unnecessary subtree-mergeinfo changes [2].
>> >
>> > [1] https://www.open.collab.net/community/subversion/articles/merge-info.html
>> > [2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>> >
>> > --
>> > Johan
>>
>> Thank you.  I don't mean updates to explicit mergeinfo, which I
>> understand from 1.7 and prior, and I have read the docs on mergeinfo
>> handling.  In 1.8 and later I've started to see explicit svn:mergeinfo
>> properties appearing on subtrees outside the context of user-initiated
>> non-root merges and am trying to follow the circumstances in which
>> they occur and whether I should stop being concerned about them.
>>
>> The earlier parts of this thread [1], where I was believing the new
>> mergeinfo properties to be inadvertent (i.e., bugs) detail my
>> confusion.  I have stopped trying to tell the Subversion authors what
>> I thought they meant to do :), and am now trying to get a solid
>> understanding going forward.
>>
>> I (and others) had been inferring non-root merges when seeing explicit
>> subtree mergeinfo (an inference informed by the articles that you
>> cite), and believe on the basis of this thread that I have to stop
>> doing that if I want to use 1.8 or newer.  Because of the necessity to
>> explain the rules to our developers, I was hoping for further
>> clarification of those rules here.
>>
>
> I think it's fairly accurate to say that a merge will only create/update
> svn:mergeinfo on:
>
> 1. The merge target (i.e., usually the root of some branch).
>
> 2. Descendants of #1 that already have svn:mergeinfo properties.
>
> 3. Descendants of #1 that have a child or sibling that is switched or
> excluded by authz (called "server-excluded" in the code) or excluded by
> depth setting or not the same revision (in the 'svn info | grep
> ^Revision:' sense) as its parent.
>
> Put another way, if you have a uniform-revision working copy with no
> subtrees that are (switched or excluded-by-depth or server-excluded),
> then svn:mergeinfo changes will only occur on the target root and on
> files/dirs that already had svn:mergeinfo properties before the merge
> started.
>
> Daniel
>
>> [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
>>
>> Thanks,
>>
>> --Pete

That was my understanding also, but this isn't the behavior in 1.8
(see this thread).  I reported the change as a bug, but Subversion's
maintainers say that the new behavior is normal (which is what this
thread has been about).  Hence my attempt to clarify what the rules
are, or whether I need to stop caring about explicit mergeinfo (or
stay with 1.7).

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Daniel Shahaf <d....@daniel.shahaf.name>]

Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pc...@gmail.com> wrote:
> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
> >>> Is it accurate then to say that Subversion may generate explicit
> >>> mergeinfo whenever it decides that there is something useful to record
> >>> about the set of revisions that contributed to a given node, and that
> >>> svn:mergeinfo properties may appear in subnodes as part of normal
> >>> Subversion merging bookkeeping, and this doesn't imply lack of a full
> >>> root->root merge or other user shenanigans?
> >>>
> >>> I appreciate your time on this.
> >>
> >> Hi,
> >>
> >> Is that an accurate description?  I'm not trying to file a bug report
> >> anymore, I'm just looking to understand the intent of this property so
> >> we can know what to expect when moving forward from 1.7.
> >>
> >> Thanks for your help,
> >>
> >
> > Yes, I think it's possible that svn records mergeinfo on subnodes
> > (directories or files), even if there is nothing to do there. It
> > happens for instance when that subnode already has some explicit
> > mergeinfo (explicit, as opposed to inherited), because of some
> > previous merge. As soon as a node has explicit mergeinfo, that
> > explicit mergeinfo needs to be updated on every merge to the root of
> > the branch.
> >
> > I'm trying to explain from memory here, possibly not entirely
> > accurate. I think you should really start by reading this article [1]
> > describing the merge tracking introduced in 1.5 (it has undergone
> > changes and many bugfixes since then, but the underlying principles
> > are still the same). It explains nicely some important terms such as
> > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
> > etc..
> >
> > Also, some changes were made in 1.7 to reduce the amount of
> > unnecessary subtree-mergeinfo changes [2].
> >
> > [1] https://www.open.collab.net/community/subversion/articles/merge-info.html
> > [2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
> >
> > --
> > Johan
> 
> Thank you.  I don't mean updates to explicit mergeinfo, which I
> understand from 1.7 and prior, and I have read the docs on mergeinfo
> handling.  In 1.8 and later I've started to see explicit svn:mergeinfo
> properties appearing on subtrees outside the context of user-initiated
> non-root merges and am trying to follow the circumstances in which
> they occur and whether I should stop being concerned about them.
> 
> The earlier parts of this thread [1], where I was believing the new
> mergeinfo properties to be inadvertent (i.e., bugs) detail my
> confusion.  I have stopped trying to tell the Subversion authors what
> I thought they meant to do :), and am now trying to get a solid
> understanding going forward.
> 
> I (and others) had been inferring non-root merges when seeing explicit
> subtree mergeinfo (an inference informed by the articles that you
> cite), and believe on the basis of this thread that I have to stop
> doing that if I want to use 1.8 or newer.  Because of the necessity to
> explain the rules to our developers, I was hoping for further
> clarification of those rules here.
> 

I think it's fairly accurate to say that a merge will only create/update
svn:mergeinfo on:

1. The merge target (i.e., usually the root of some branch).

2. Descendants of #1 that already have svn:mergeinfo properties.

3. Descendants of #1 that have a child or sibling that is switched or
excluded by authz (called "server-excluded" in the code) or excluded by
depth setting or not the same revision (in the 'svn info | grep
^Revision:' sense) as its parent.

Put another way, if you have a uniform-revision working copy with no
subtrees that are (switched or excluded-by-depth or server-excluded),
then svn:mergeinfo changes will only occur on the target root and on
files/dirs that already had svn:mergeinfo properties before the merge
started.

Daniel

> [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
> 
> Thanks,
> 
> --Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pc...@gmail.com> wrote:
>> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
>>> Is it accurate then to say that Subversion may generate explicit
>>> mergeinfo whenever it decides that there is something useful to record
>>> about the set of revisions that contributed to a given node, and that
>>> svn:mergeinfo properties may appear in subnodes as part of normal
>>> Subversion merging bookkeeping, and this doesn't imply lack of a full
>>> root->root merge or other user shenanigans?
>>>
>>> I appreciate your time on this.
>>
>> Hi,
>>
>> Is that an accurate description?  I'm not trying to file a bug report
>> anymore, I'm just looking to understand the intent of this property so
>> we can know what to expect when moving forward from 1.7.
>>
>> Thanks for your help,
>>
>
> Yes, I think it's possible that svn records mergeinfo on subnodes
> (directories or files), even if there is nothing to do there. It
> happens for instance when that subnode already has some explicit
> mergeinfo (explicit, as opposed to inherited), because of some
> previous merge. As soon as a node has explicit mergeinfo, that
> explicit mergeinfo needs to be updated on every merge to the root of
> the branch.
>
> I'm trying to explain from memory here, possibly not entirely
> accurate. I think you should really start by reading this article [1]
> describing the merge tracking introduced in 1.5 (it has undergone
> changes and many bugfixes since then, but the underlying principles
> are still the same). It explains nicely some important terms such as
> 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
> etc..
>
> Also, some changes were made in 1.7 to reduce the amount of
> unnecessary subtree-mergeinfo changes [2].
>
> [1] https://www.open.collab.net/community/subversion/articles/merge-info.html
> [2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>
> --
> Johan

Thank you.  I don't mean updates to explicit mergeinfo, which I
understand from 1.7 and prior, and I have read the docs on mergeinfo
handling.  In 1.8 and later I've started to see explicit svn:mergeinfo
properties appearing on subtrees outside the context of user-initiated
non-root merges and am trying to follow the circumstances in which
they occur and whether I should stop being concerned about them.

The earlier parts of this thread [1], where I was believing the new
mergeinfo properties to be inadvertent (i.e., bugs) detail my
confusion.  I have stopped trying to tell the Subversion authors what
I thought they meant to do :), and am now trying to get a solid
understanding going forward.

I (and others) had been inferring non-root merges when seeing explicit
subtree mergeinfo (an inference informed by the articles that you
cite), and believe on the basis of this thread that I have to stop
doing that if I want to use 1.8 or newer.  Because of the necessity to
explain the rules to our developers, I was hoping for further
clarification of those rules here.

[1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260

Thanks,

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Johan Corveleyn <jc...@gmail.com>]

On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pc...@gmail.com> wrote:
> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
>> Is it accurate then to say that Subversion may generate explicit
>> mergeinfo whenever it decides that there is something useful to record
>> about the set of revisions that contributed to a given node, and that
>> svn:mergeinfo properties may appear in subnodes as part of normal
>> Subversion merging bookkeeping, and this doesn't imply lack of a full
>> root->root merge or other user shenanigans?
>>
>> I appreciate your time on this.
>
> Hi,
>
> Is that an accurate description?  I'm not trying to file a bug report
> anymore, I'm just looking to understand the intent of this property so
> we can know what to expect when moving forward from 1.7.
>
> Thanks for your help,
>

Yes, I think it's possible that svn records mergeinfo on subnodes
(directories or files), even if there is nothing to do there. It
happens for instance when that subnode already has some explicit
mergeinfo (explicit, as opposed to inherited), because of some
previous merge. As soon as a node has explicit mergeinfo, that
explicit mergeinfo needs to be updated on every merge to the root of
the branch.

I'm trying to explain from memory here, possibly not entirely
accurate. I think you should really start by reading this article [1]
describing the merge tracking introduced in 1.5 (it has undergone
changes and many bugfixes since then, but the underlying principles
are still the same). It explains nicely some important terms such as
'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
etc..

Also, some changes were made in 1.7 to reduce the amount of
unnecessary subtree-mergeinfo changes [2].

[1] https://www.open.collab.net/community/subversion/articles/merge-info.html
[2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording

-- 
Johan

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pc...@gmail.com> wrote:
> Is it accurate then to say that Subversion may generate explicit
> mergeinfo whenever it decides that there is something useful to record
> about the set of revisions that contributed to a given node, and that
> svn:mergeinfo properties may appear in subnodes as part of normal
> Subversion merging bookkeeping, and this doesn't imply lack of a full
> root->root merge or other user shenanigans?
>
> I appreciate your time on this.

Hi,

Is that an accurate description?  I'm not trying to file a bug report
anymore, I'm just looking to understand the intent of this property so
we can know what to expect when moving forward from 1.7.

Thanks for your help,

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

Is it accurate then to say that Subversion may generate explicit
mergeinfo whenever it decides that there is something useful to record
about the set of revisions that contributed to a given node, and that
svn:mergeinfo properties may appear in subnodes as part of normal
Subversion merging bookkeeping, and this doesn't imply lack of a full
root->root merge or other user shenanigans?

I appreciate your time on this.

Thanks,

--Pete

On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan <pc...@gmail.com> wrote:
> On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej <br...@wandisco.com> wrote:
>>>> In an ideal world, you colleague's argument would be wrong: the merge
>>>> should record what was actually merged, not what the merge command
>>>> intended. So, in cases as the one that started this discussion — when
>>>> part of the tree cannot be merged due to a conflict — the mergeinfo
>>>> should report that. Removing that not from mergeinfo should be an
>>>> integral part of the conflict resolution.
>>>>
>>>> In other words, mergeinfo should always show what /actually/ happened,
>>>> not what we wish had happened.
>>>>
>>>> --  Brane
>>> Doesn't the conflicted state of a path already indicate what actually
>>> happened?  There can be no mistake about those portions of the merge
>>> being incomplete.
>>
>> "Conflict" is a transient property of the working copy. "Mergeinfo" is
>> an attribute of the repository and is a permanent record. In most
>> conflict cases there are at least two ways to resolve the conflict, each
>> of which could produce a different answer to the question "what was merged?"
>
> The user decides "what was merged" by passing arguments to the "svn
> merge" command.  Conflict resolution determines what files constitute
> the correct result of that merge.
>
> The user decides what "svn merge X Y" looks like, and only they can be
> the authority on that.  It may involve fixing semantic conflicts, it
> may involve throwing away half the tree: that's up to the user.  But
> it has no bearing on whether the result is to be considered a merge
> from X to Y.  That is the meaning of "svn merge X Y".
>
> Conflicts are Subversion saying "I need help merging these two paths;
> here's how I'm confused".  Solving that confusion does not change the
> answer to the question "what was merged?"
>
>>> If the svn developers do decide that introducing mergeinfo for [some?
>>> why not all?] conflicted paths is the correct scenario, I would think
>>> that that shouldn't be done until resolve knows how to clean it up.
>>
>> See above re ideal world ... currently it's far from ideal. One could
>> argue that it's better to improve some cases, rather than hope to get
>> them all covered in one go.
>>
>> In the case we're debating: if a normal conflict resolution leaves
>> unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If
>> it doesn't, then it's working correctly, even if not as expected, IMO.
>
> We seem to disagree on what mergeinfo is for.  Here's a case where I
> want subtree mergeinfo:
>
> 1. Branch X merges from trunk.  All mergeinfo was at root of X prior
> to the merge, and it is so after the merge.
> 2. A subtree of X merges from a subtree of branch Y.  Now there's a
> mergeinfo at the root of X and at the root of the subtree.
> 3. Branch X merges from trunk again.  We still need mergeinfo at X and
> at the subtree, because the subtree contains revisions (from Y) that X
> does not.
> 4. Branch X merges from branch Y.  Subversion uses its extra info at
> the root of the subtree to help with the merge.
>
> At the conclusion of #4, Subversion will probably still have mergeinfo
> at the root of X and at the root of X's subtree; the subtree mergeinfo
> property is redundant now because both X and the subtree include all
> the same revisions of the trunk and of branch Y.
>
> In an ideal world, Subversion could remove the now-redundant subtree
> mergeinfo after #4; I'm not asking for that.  But it would be a *bug*
> for it to have separate subtree info after #1.  That it does, is what
> I'm reporting.
>
> In case this helps, here's what's motivating my report.  We have a
> policy against subtree merges: users are only allowed to commit merges
> performed between branch/trunk roots.  We enforce that policy by
> rejecting commits that add svn:mergeinfo properties to interior nodes.
> In my understanding, this is a correct way to enforce the policy,
> because subtree merges are what interior svn:mergeinfo properties are
> for.
>
> --Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej <br...@wandisco.com> wrote:
>>> In an ideal world, you colleague's argument would be wrong: the merge
>>> should record what was actually merged, not what the merge command
>>> intended. So, in cases as the one that started this discussion — when
>>> part of the tree cannot be merged due to a conflict — the mergeinfo
>>> should report that. Removing that not from mergeinfo should be an
>>> integral part of the conflict resolution.
>>>
>>> In other words, mergeinfo should always show what /actually/ happened,
>>> not what we wish had happened.
>>>
>>> --  Brane
>> Doesn't the conflicted state of a path already indicate what actually
>> happened?  There can be no mistake about those portions of the merge
>> being incomplete.
>
> "Conflict" is a transient property of the working copy. "Mergeinfo" is
> an attribute of the repository and is a permanent record. In most
> conflict cases there are at least two ways to resolve the conflict, each
> of which could produce a different answer to the question "what was merged?"

The user decides "what was merged" by passing arguments to the "svn
merge" command.  Conflict resolution determines what files constitute
the correct result of that merge.

The user decides what "svn merge X Y" looks like, and only they can be
the authority on that.  It may involve fixing semantic conflicts, it
may involve throwing away half the tree: that's up to the user.  But
it has no bearing on whether the result is to be considered a merge
from X to Y.  That is the meaning of "svn merge X Y".

Conflicts are Subversion saying "I need help merging these two paths;
here's how I'm confused".  Solving that confusion does not change the
answer to the question "what was merged?"

>> If the svn developers do decide that introducing mergeinfo for [some?
>> why not all?] conflicted paths is the correct scenario, I would think
>> that that shouldn't be done until resolve knows how to clean it up.
>
> See above re ideal world ... currently it's far from ideal. One could
> argue that it's better to improve some cases, rather than hope to get
> them all covered in one go.
>
> In the case we're debating: if a normal conflict resolution leaves
> unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If
> it doesn't, then it's working correctly, even if not as expected, IMO.

We seem to disagree on what mergeinfo is for.  Here's a case where I
want subtree mergeinfo:

1. Branch X merges from trunk.  All mergeinfo was at root of X prior
to the merge, and it is so after the merge.
2. A subtree of X merges from a subtree of branch Y.  Now there's a
mergeinfo at the root of X and at the root of the subtree.
3. Branch X merges from trunk again.  We still need mergeinfo at X and
at the subtree, because the subtree contains revisions (from Y) that X
does not.
4. Branch X merges from branch Y.  Subversion uses its extra info at
the root of the subtree to help with the merge.

At the conclusion of #4, Subversion will probably still have mergeinfo
at the root of X and at the root of X's subtree; the subtree mergeinfo
property is redundant now because both X and the subtree include all
the same revisions of the trunk and of branch Y.

In an ideal world, Subversion could remove the now-redundant subtree
mergeinfo after #4; I'm not asking for that.  But it would be a *bug*
for it to have separate subtree info after #1.  That it does, is what
I'm reporting.

In case this helps, here's what's motivating my report.  We have a
policy against subtree merges: users are only allowed to commit merges
performed between branch/trunk roots.  We enforce that policy by
rejecting commits that add svn:mergeinfo properties to interior nodes.
In my understanding, this is a correct way to enforce the policy,
because subtree merges are what interior svn:mergeinfo properties are
for.

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Branko Čibej <br...@wandisco.com>]

On 16.03.2015 22:15, Pete Harlan wrote:
> On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej <br...@wandisco.com> wrote:
>>> A colleague argued that creating the mergeinfo for a subtree in this
>>> case (root->root merge) is a simple bug because mergeinfo says what
>>> inputs were considered to come up with the result, not just those that
>>> were used.
>>>
>>> 1. If the resulting mergeinfo is the same as for root then it's
>>> unnecessary, so the bug is that it is explicitly listed at all.
>>>
>>> 2. If the resulting mergeinfo is different than then root one then
>>> it's incorrect, because it's claiming that the subtree working copy
>>> represents the merge of a different set of branches and revisions than
>>> the root working copy it's included within.
>>>
>>> In other words, it would always be wrong for a merge to introduce
>>> explicit mergeinfo for a subtree of the merge point.
>>>
>>> This implies that the fix wouldn't be to change how resolve works, it
>>> would be for "svn merge" to not create the property on the subtree in
>>> the first place.
>>>
>>> What do you think?
>> In an ideal world, you colleague's argument would be wrong: the merge
>> should record what was actually merged, not what the merge command
>> intended. So, in cases as the one that started this discussion — when
>> part of the tree cannot be merged due to a conflict — the mergeinfo
>> should report that. Removing that not from mergeinfo should be an
>> integral part of the conflict resolution.
>>
>> In other words, mergeinfo should always show what /actually/ happened,
>> not what we wish had happened.
>>
>> --  Brane
> Doesn't the conflicted state of a path already indicate what actually
> happened?  There can be no mistake about those portions of the merge
> being incomplete.

"Conflict" is a transient property of the working copy. "Mergeinfo" is
an attribute of the repository and is a permanent record. In most
conflict cases there are at least two ways to resolve the conflict, each
of which could produce a different answer to the question "what was merged?"

> If the svn developers do decide that introducing mergeinfo for [some?
> why not all?] conflicted paths is the correct scenario, I would think
> that that shouldn't be done until resolve knows how to clean it up.

See above re ideal world ... currently it's far from ideal. One could
argue that it's better to improve some cases, rather than hope to get
them all covered in one go.

In the case we're debating: if a normal conflict resolution leaves
unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If
it doesn't, then it's working correctly, even if not as expected, IMO.

-- Brane

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej <br...@wandisco.com> wrote:
>> A colleague argued that creating the mergeinfo for a subtree in this
>> case (root->root merge) is a simple bug because mergeinfo says what
>> inputs were considered to come up with the result, not just those that
>> were used.
>>
>> 1. If the resulting mergeinfo is the same as for root then it's
>> unnecessary, so the bug is that it is explicitly listed at all.
>>
>> 2. If the resulting mergeinfo is different than then root one then
>> it's incorrect, because it's claiming that the subtree working copy
>> represents the merge of a different set of branches and revisions than
>> the root working copy it's included within.
>>
>> In other words, it would always be wrong for a merge to introduce
>> explicit mergeinfo for a subtree of the merge point.
>>
>> This implies that the fix wouldn't be to change how resolve works, it
>> would be for "svn merge" to not create the property on the subtree in
>> the first place.
>>
>> What do you think?
>
> In an ideal world, you colleague's argument would be wrong: the merge
> should record what was actually merged, not what the merge command
> intended. So, in cases as the one that started this discussion — when
> part of the tree cannot be merged due to a conflict — the mergeinfo
> should report that. Removing that not from mergeinfo should be an
> integral part of the conflict resolution.
>
> In other words, mergeinfo should always show what /actually/ happened,
> not what we wish had happened.
>
> --  Brane

Doesn't the conflicted state of a path already indicate what actually
happened?  There can be no mistake about those portions of the merge
being incomplete.

If the svn developers do decide that introducing mergeinfo for [some?
why not all?] conflicted paths is the correct scenario, I would think
that that shouldn't be done until resolve knows how to clean it up.

Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Branko Čibej <br...@wandisco.com>]

On 16.03.2015 19:02, Pete Harlan wrote:
> On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan <pc...@gmail.com> wrote:
>> As you pointed out, my original report erroneously focused on
>> svn:mergeinfo appearing, when the real issue is that the new
>> svn:mergeinfo doesn't disappear (still) when the user marks the
>> conflict resolved.  (And I haven't found a way to remove it besides
>> propdel; "svn merge --record-only ^/trunk" has no effect afaict.)
>>
>> My expectation as a naive user is: I initiated a merge from the root
>> of a branch (or trunk), I told svn to merge the root of another branch
>> (or trunk), and I resolved all reported conflicts (however complex).
>> Unless I've explicitly told svn otherwise, I expect svn to consider
>> this a full merge, and not create separate mergeinfo for any interior
>> nodes.
>>
>> So I think it would be worth updating "svn resolve" to, by default,
>> take action to trust the user and mark this as a full resolution.  If
>> the user needs to take an extra step or add a new parameter to get
>> that effect, would that not feel like a regression compared with 1.7?
> A colleague argued that creating the mergeinfo for a subtree in this
> case (root->root merge) is a simple bug because mergeinfo says what
> inputs were considered to come up with the result, not just those that
> were used.
>
> 1. If the resulting mergeinfo is the same as for root then it's
> unnecessary, so the bug is that it is explicitly listed at all.
>
> 2. If the resulting mergeinfo is different than then root one then
> it's incorrect, because it's claiming that the subtree working copy
> represents the merge of a different set of branches and revisions than
> the root working copy it's included within.
>
> In other words, it would always be wrong for a merge to introduce
> explicit mergeinfo for a subtree of the merge point.
>
> This implies that the fix wouldn't be to change how resolve works, it
> would be for "svn merge" to not create the property on the subtree in
> the first place.
>
> What do you think?

In an ideal world, you colleague's argument would be wrong: the merge
should record what was actually merged, not what the merge command
intended. So, in cases as the one that started this discussion — when
part of the tree cannot be merged due to a conflict — the mergeinfo
should report that. Removing that not from mergeinfo should be an
integral part of the conflict resolution.

In other words, mergeinfo should always show what /actually/ happened,
not what we wish had happened.

--  Brane

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Julian Foad <ju...@btopenworld.com>]

Hi Pete. Just one quick point before I take the time to digest
everything else...

Pete Harlan wrote:
> I wrote a list of cases I could think of to test, and tested them
> against 1.8.13.
[...]
> FAILED: dir-add-add.sh  (Dir of same name added to both sides.)
> FAILED: dir-copy-add.sh  (Same, only one was added via copy the other as new.)
> FAILED: dir-file-add-add.sh  (File added to one side, dir of same name
> added to other.)
[...]
> My scripts are Bash scripts similar to the script I originally posted
> to this thread.  I can share them if you think that would be useful,
> or I'm happy to rerun them against other versions upon request.

Please do share them! As a matter of course, attaching any scripts you
use, however simple, is a great way to lower the barrier for anybody
else to join in the effort.

- Julian

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Mon, Apr 13, 2015 at 10:58 AM, Pete Harlan <pc...@gmail.com> wrote:
>> My scripts are Bash scripts similar to the script I originally posted
>> to this thread.  I can share them if you think that would be useful,
>> or I'm happy to rerun them against other versions upon request.
...
> Attached.  Disclaimer: they were written to optimize the time spent
> initially writing them, not reading or maintaining them :-)  There's a
> lot of copy+pasting here, inconsistent style, etc.  I looked at
> writing proper tests using your Python framework but wasn't able to
> take the time to learn that setup.
>
> Also, written for a Linux+bash environment; not tested anywhere else.
>
> There's a README describing how to run them, but it's basically "runAll.sh

Updated version attached, which doesn't require the user to issue a
full path to the runAll.sh script.  Grr...

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Fri, Apr 10, 2015 at 6:40 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 11.04.2015 02:01, Pete Harlan wrote:
>> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <ju...@btopenworld.com> wrote:
>>> Pete Harlan wrote:
>> ...
>>>> If you have suggestions for how I could further help this issue along,
>>>> please let me know.  And thanks again very much for your time.
>>> It would help to catalogue the various cases. Maybe start with an
>>> premise that a whole tree merge should not generate any subtree
>>> mergeinfo and start finding the exceptions that currently occur.
>> I wrote a list of cases I could think of to test, and tested them
>> against 1.8.13.
>>
>> Of the cases I considered and tested, the subtree mergeinfo appeared
>> if and only if a *directory* node was part of a tree conflict
>> (regardless of what it conflicted with). "PASSED" here means no
>> subtree merge info was created, and "FAILED" means it was created.
>>
>> In all cases, "svn resolve --accept=working <conflicted path>" was run
>> prior to looking for subtree mergeinfo.
>>
>> PASSED: dir-add-delete.sh  (One side adds a dir, the other added and
>> deleted a dir of the same name)
>> PASSED: dir-delete-delete.sh  (Both sides deleted a common dir.)
>> PASSED: file-add-add.sh  (Both sides added a file with the same name.)
>> PASSED: file-add-delete.sh  (One side added a file, the other added
>> and deleted the file.)
>> PASSED: file-copy-add.sh  (One side added a file via copy, the other
>> via creating a new file.)
>> PASSED: file-delete-delete.sh  (Both sides deleted the same file.)
>> PASSED: file-edit-delete.sh  (One side edited a file, the other deleted it.)
>> PASSED: file-edit-edit.sh  (Both sides edited a file in conflicting ways.)
>> PASSED: no-conflict.sh  (Clean merge.)
>>
>> FAILED: dir-add-add.sh  (Dir of same name added to both sides.)
>> FAILED: dir-copy-add.sh  (Same, only one was added via copy the other as new.)
>> FAILED: dir-file-add-add.sh  (File added to one side, dir of same name
>> added to other.)
>>
>> Current trunk fails the same tests.  All tests pass with 1.7.20 and 1.6.23.
>>
>> My scripts are Bash scripts similar to the script I originally posted
>> to this thread.  I can share them if you think that would be useful,
>> or I'm happy to rerun them against other versions upon request.
>
>
> It would be wonderful if you could share those scripts; it saves time
> when everyone uses the same test scripts to discuss behaviour, and we'd
> surely like to incorporate any new scenario into our test suite.

Attached.  Disclaimer: they were written to optimize the time spent
initially writing them, not reading or maintaining them :-)  There's a
lot of copy+pasting here, inconsistent style, etc.  I looked at
writing proper tests using your Python framework but wasn't able to
take the time to learn that setup.

Also, written for a Linux+bash environment; not tested anywhere else.

There's a README describing how to run them, but it's basically "runAll.sh

>>> Another way to help would be to think about how the client could
>>> present the "WC is in a merged state" notion, and how that would
>>> affect various operations. Just assume that we can implement it, and
>>> imagine how it should behave in order to be useful. Is there a hard
>>> dividing line between "is" and "is not" in a "merged" state for the
>>> whole WC -- what if we *want* to merge subtrees separately? Does this
>>> "state" need more degrees of subtlety in some other way too?
>> When the WC is in a merged state, doesn't it necessarily contain
>> modifications to the merge-root svn:mergeinfo property?  It seems
>> reasonable to me to have Subversion error out from initiating a new
>> merge if it is currently in the middle of a merge (as identified by a
>> modified svn:mergeinfo property), with a message like "You are in the
>> middle of merging <url> to <WC path>; please complete that before
>> merging again or revert it with <...>".
>
> This does sound like a logical approach. The problem is that what looks
> like a single merge from the user's perspective can actually be a series
> of merges, where each merge depends on the results (including locally
> modified mergeinfo) of the previous merge. Consider the simplest case,
> with B branched from A in r5, and r10 cherry-picked from B to A. A full
> merge of r15 from B to A will actually be split into two merges of two
> revision ranges: [6..9] and [11..15], skipping the already-merged r10.

When I say that Subversion would error out from initiating a new
merge, I don't mean that internally the client couldn't process the
merge in steps, only that the user couldn't initiate a new "svn merge"
command in a repo that is in the middle of an existing merge.

An exception would be if the merge was one where the client stops and
says "please resolve the conflicts and rerun the merge".  In that case
the user has to rerun the merge command in a WC that is in a "merging"
state.  I can think of two ways of handling that:

a. Record somewhere what "the current merge" is, and allow the user to
perform that and only that merge command, or

b. Require the user to indicate that this is a continuation merge
("svn merge --continue ...").

I prefer #a because there's less chance for the user to continue a
merge incorrectly by adding the wrong arguments.  (Or both: if you
recorded what the merge is, then "svn merge --continue" could continue
the merge without the user retyping the rest of the arguments.)

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Branko Čibej <br...@wandisco.com>]

On 11.04.2015 02:01, Pete Harlan wrote:
> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <ju...@btopenworld.com> wrote:
>> Pete Harlan wrote:
> ...
>>> If you have suggestions for how I could further help this issue along,
>>> please let me know.  And thanks again very much for your time.
>> It would help to catalogue the various cases. Maybe start with an
>> premise that a whole tree merge should not generate any subtree
>> mergeinfo and start finding the exceptions that currently occur.
> I wrote a list of cases I could think of to test, and tested them
> against 1.8.13.
>
> Of the cases I considered and tested, the subtree mergeinfo appeared
> if and only if a *directory* node was part of a tree conflict
> (regardless of what it conflicted with). "PASSED" here means no
> subtree merge info was created, and "FAILED" means it was created.
>
> In all cases, "svn resolve --accept=working <conflicted path>" was run
> prior to looking for subtree mergeinfo.
>
> PASSED: dir-add-delete.sh  (One side adds a dir, the other added and
> deleted a dir of the same name)
> PASSED: dir-delete-delete.sh  (Both sides deleted a common dir.)
> PASSED: file-add-add.sh  (Both sides added a file with the same name.)
> PASSED: file-add-delete.sh  (One side added a file, the other added
> and deleted the file.)
> PASSED: file-copy-add.sh  (One side added a file via copy, the other
> via creating a new file.)
> PASSED: file-delete-delete.sh  (Both sides deleted the same file.)
> PASSED: file-edit-delete.sh  (One side edited a file, the other deleted it.)
> PASSED: file-edit-edit.sh  (Both sides edited a file in conflicting ways.)
> PASSED: no-conflict.sh  (Clean merge.)
>
> FAILED: dir-add-add.sh  (Dir of same name added to both sides.)
> FAILED: dir-copy-add.sh  (Same, only one was added via copy the other as new.)
> FAILED: dir-file-add-add.sh  (File added to one side, dir of same name
> added to other.)
>
> Current trunk fails the same tests.  All tests pass with 1.7.20 and 1.6.23.
>
> My scripts are Bash scripts similar to the script I originally posted
> to this thread.  I can share them if you think that would be useful,
> or I'm happy to rerun them against other versions upon request.


It would be wonderful if you could share those scripts; it saves time
when everyone uses the same test scripts to discuss behaviour, and we'd
surely like to incorporate any new scenario into our test suite.


>> Another way to help would be to think about how the client could
>> present the "WC is in a merged state" notion, and how that would
>> affect various operations. Just assume that we can implement it, and
>> imagine how it should behave in order to be useful. Is there a hard
>> dividing line between "is" and "is not" in a "merged" state for the
>> whole WC -- what if we *want* to merge subtrees separately? Does this
>> "state" need more degrees of subtlety in some other way too?
> When the WC is in a merged state, doesn't it necessarily contain
> modifications to the merge-root svn:mergeinfo property?  It seems
> reasonable to me to have Subversion error out from initiating a new
> merge if it is currently in the middle of a merge (as identified by a
> modified svn:mergeinfo property), with a message like "You are in the
> middle of merging <url> to <WC path>; please complete that before
> merging again or revert it with <...>".

This does sound like a logical approach. The problem is that what looks
like a single merge from the user's perspective can actually be a series
of merges, where each merge depends on the results (including locally
modified mergeinfo) of the previous merge. Consider the simplest case,
with B branched from A in r5, and r10 cherry-picked from B to A. A full
merge of r15 from B to A will actually be split into two merges of two
revision ranges: [6..9] and [11..15], skipping the already-merged r10.

-- Brane

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Pete Harlan wrote:
>> Julian Foad wrote:
> [...]
>>> Another way to help would be to think about how the client could
>>> present the "WC is in a merged state" notion, and how that would
>>> affect various operations. Just assume that we can implement it, and
>>> imagine how it should behave in order to be useful. Is there a hard
>>> dividing line between "is" and "is not" in a "merged" state for the
>>> whole WC -- what if we *want* to merge subtrees separately? Does this
>>> "state" need more degrees of subtlety in some other way too?
>>
>> When the WC is in a merged state, doesn't it necessarily contain
>> modifications to the merge-root svn:mergeinfo property?
>
> Not necessarily. Not if I ran a subtree merge, such as
>
>     svn merge ^/branches/source-branch/subtree ./subtree

But in this example, ./subtree is the merge root, and it's subtree's
mergeinfo that is modified (in 1.8.13), so this agrees with what I
suggested.

(I may be using "merge root" in a nonstandard way: I mean the points
in the WC and the source URL that are being merged.)

>>  It seems
>> reasonable to me to have Subversion error out from initiating a new
>> merge if it is currently in the middle of a merge (as identified by a
>> modified svn:mergeinfo property), with a message like "You are in the
>> middle of merging <url> to <WC path>; please complete that before
>> merging again or revert it with <...>".
>
> Sometimes, particularly if I know there's a big change or an intrusive
> change among all the changes I want to merge from a given source
> branch, it is nice to be able to merge a portion of all the source
> changes I really want (a restricted revision range and/or a restricted
> subtree), and resolve conflicts and check it's looking ok, and then
> merge another portion or all the rest of the changes. That can help me
> to deal with complex conflicts better.
>
> But in general, I expect most people do most merges in one go, and
> what you suggest might indeed be helpful. We just might want a bypass
> for the intentional cases. That's no problem, we can have a bypass.

That is a case I hadn't considered, but it sounds reasonable and I
think a bypass would make sense here.

>> Any modification to other nodes' mergeinfo would be done only by
>> "resolve", which by default would resolve as a "full merge" as
>> initiated by the user (and thus not add explicit mergeinfo), and if
>> you want to handle merges that omit interior nodes from the merge
>> (why?)
>
> I might want to omit part of the tree from the merge if, for example,
> the tree consists of one subtree 'src' containing lots of source code,
> and another 'doc' containing lots of documentation, and the merge
> turns out to have lots of changes and lots of conflicts in both areas,
> and I decide that instead of completing all the conflict resolution in
> both subtrees I'd rather concentrate on getting everything under 'src'
> properly merged and leave the 'doc' for later. I might want to commit
> this result, a result that says everything except the content of 'doc'
> is merged, so that I or someone else can then merge the 'doc' subtree
> later. Does that make sense, at least hypothetically?

Yes, that makes a lot of sense.  It's a way to collaborate on a merge,
with the downside being that commits are made that represent an
inconsistent state of the code (but that may be the best solution in
some cases).

--Pete

>> then you would do so with a new option to resolve, something
>> like "svn resolve --accept=omit-from-merge <path>".  If *that* command
>> created interior mergeinfo, that would probably coincide with user
>> expectation.
>
> Yes, that sort of thing sounds reasonable.
>
>> I am aware that my analysis is naive regarding both Subversion's
>> implementation and the universe of potential use-cases, but for the
>> way I use Subversion this seems reasonable to me.
>>
>> I'm also wondering if something could be done more expediently: Is
>> Subversion doing anything useful with the subtree mergeinfo that
>> appeared in 1.8?  If not, then perhaps it could disappear until the
>> feature it's part of is more fleshed out (i.e., until a solution that
>> includes ways for the user to pass their intent to "resolve" is
>> added).  Again, I don't know Subversion internals so maybe Subversion
>> is doing something useful with that information that I'm unaware of.
>
> Hmm, I'm not sure about that.
>
> - Julian

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Julian Foad <ju...@btopenworld.com>]

Pete Harlan wrote:
> Julian Foad wrote:
[...]
>> Another way to help would be to think about how the client could
>> present the "WC is in a merged state" notion, and how that would
>> affect various operations. Just assume that we can implement it, and
>> imagine how it should behave in order to be useful. Is there a hard
>> dividing line between "is" and "is not" in a "merged" state for the
>> whole WC -- what if we *want* to merge subtrees separately? Does this
>> "state" need more degrees of subtlety in some other way too?
>
> When the WC is in a merged state, doesn't it necessarily contain
> modifications to the merge-root svn:mergeinfo property?

Not necessarily. Not if I ran a subtree merge, such as

    svn merge ^/branches/source-branch/subtree ./subtree

>  It seems
> reasonable to me to have Subversion error out from initiating a new
> merge if it is currently in the middle of a merge (as identified by a
> modified svn:mergeinfo property), with a message like "You are in the
> middle of merging <url> to <WC path>; please complete that before
> merging again or revert it with <...>".

Sometimes, particularly if I know there's a big change or an intrusive
change among all the changes I want to merge from a given source
branch, it is nice to be able to merge a portion of all the source
changes I really want (a restricted revision range and/or a restricted
subtree), and resolve conflicts and check it's looking ok, and then
merge another portion or all the rest of the changes. That can help me
to deal with complex conflicts better.

But in general, I expect most people do most merges in one go, and
what you suggest might indeed be helpful. We just might want a bypass
for the intentional cases. That's no problem, we can have a bypass.

> Any modification to other nodes' mergeinfo would be done only by
> "resolve", which by default would resolve as a "full merge" as
> initiated by the user (and thus not add explicit mergeinfo), and if
> you want to handle merges that omit interior nodes from the merge
> (why?)

I might want to omit part of the tree from the merge if, for example,
the tree consists of one subtree 'src' containing lots of source code,
and another 'doc' containing lots of documentation, and the merge
turns out to have lots of changes and lots of conflicts in both areas,
and I decide that instead of completing all the conflict resolution in
both subtrees I'd rather concentrate on getting everything under 'src'
properly merged and leave the 'doc' for later. I might want to commit
this result, a result that says everything except the content of 'doc'
is merged, so that I or someone else can then merge the 'doc' subtree
later. Does that make sense, at least hypothetically?

> then you would do so with a new option to resolve, something
> like "svn resolve --accept=omit-from-merge <path>".  If *that* command
> created interior mergeinfo, that would probably coincide with user
> expectation.

Yes, that sort of thing sounds reasonable.

> I am aware that my analysis is naive regarding both Subversion's
> implementation and the universe of potential use-cases, but for the
> way I use Subversion this seems reasonable to me.
>
> I'm also wondering if something could be done more expediently: Is
> Subversion doing anything useful with the subtree mergeinfo that
> appeared in 1.8?  If not, then perhaps it could disappear until the
> feature it's part of is more fleshed out (i.e., until a solution that
> includes ways for the user to pass their intent to "resolve" is
> added).  Again, I don't know Subversion internals so maybe Subversion
> is doing something useful with that information that I'm unaware of.

Hmm, I'm not sure about that.

- Julian

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Pete Harlan wrote:
...
>> If you have suggestions for how I could further help this issue along,
>> please let me know.  And thanks again very much for your time.
>
> It would help to catalogue the various cases. Maybe start with an
> premise that a whole tree merge should not generate any subtree
> mergeinfo and start finding the exceptions that currently occur.

I wrote a list of cases I could think of to test, and tested them
against 1.8.13.

Of the cases I considered and tested, the subtree mergeinfo appeared
if and only if a *directory* node was part of a tree conflict
(regardless of what it conflicted with). "PASSED" here means no
subtree merge info was created, and "FAILED" means it was created.

In all cases, "svn resolve --accept=working <conflicted path>" was run
prior to looking for subtree mergeinfo.

PASSED: dir-add-delete.sh  (One side adds a dir, the other added and
deleted a dir of the same name)
PASSED: dir-delete-delete.sh  (Both sides deleted a common dir.)
PASSED: file-add-add.sh  (Both sides added a file with the same name.)
PASSED: file-add-delete.sh  (One side added a file, the other added
and deleted the file.)
PASSED: file-copy-add.sh  (One side added a file via copy, the other
via creating a new file.)
PASSED: file-delete-delete.sh  (Both sides deleted the same file.)
PASSED: file-edit-delete.sh  (One side edited a file, the other deleted it.)
PASSED: file-edit-edit.sh  (Both sides edited a file in conflicting ways.)
PASSED: no-conflict.sh  (Clean merge.)

FAILED: dir-add-add.sh  (Dir of same name added to both sides.)
FAILED: dir-copy-add.sh  (Same, only one was added via copy the other as new.)
FAILED: dir-file-add-add.sh  (File added to one side, dir of same name
added to other.)

Current trunk fails the same tests.  All tests pass with 1.7.20 and 1.6.23.

My scripts are Bash scripts similar to the script I originally posted
to this thread.  I can share them if you think that would be useful,
or I'm happy to rerun them against other versions upon request.

> Another way to help would be to think about how the client could
> present the "WC is in a merged state" notion, and how that would
> affect various operations. Just assume that we can implement it, and
> imagine how it should behave in order to be useful. Is there a hard
> dividing line between "is" and "is not" in a "merged" state for the
> whole WC -- what if we *want* to merge subtrees separately? Does this
> "state" need more degrees of subtlety in some other way too?

When the WC is in a merged state, doesn't it necessarily contain
modifications to the merge-root svn:mergeinfo property?  It seems
reasonable to me to have Subversion error out from initiating a new
merge if it is currently in the middle of a merge (as identified by a
modified svn:mergeinfo property), with a message like "You are in the
middle of merging <url> to <WC path>; please complete that before
merging again or revert it with <...>".

Any modification to other nodes' mergeinfo would be done only by
"resolve", which by default would resolve as a "full merge" as
initiated by the user (and thus not add explicit mergeinfo), and if
you want to handle merges that omit interior nodes from the merge
(why?) then you would do so with a new option to resolve, something
like "svn resolve --accept=omit-from-merge <path>".  If *that* command
created interior mergeinfo, that would probably coincide with user
expectation.

I am aware that my analysis is naive regarding both Subversion's
implementation and the universe of potential use-cases, but for the
way I use Subversion this seems reasonable to me.

I'm also wondering if something could be done more expediently: Is
Subversion doing anything useful with the subtree mergeinfo that
appeared in 1.8?  If not, then perhaps it could disappear until the
feature it's part of is more fleshed out (i.e., until a solution that
includes ways for the user to pass their intent to "resolve" is
added).  Again, I don't know Subversion internals so maybe Subversion
is doing something useful with that information that I'm unaware of.

Thank you for your time,

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Julian Foad <ju...@btopenworld.com>]

Pete Harlan wrote:
> Julian Foad wrote:
[...]
>> On 2015-03-16, Pete Harlan wrote:
>>> On 2015-03-14, Pete Harlan wrote:
>>>> My expectation as a naive user is: I initiated a merge from the root
>>>> of a branch (or trunk), I told svn to merge the root of another branch
>>>> (or trunk), and I resolved all reported conflicts (however complex).
>>>> Unless I've explicitly told svn otherwise, I expect svn to consider
>>>> this a full merge, and not create separate mergeinfo for any interior
>>>> nodes.
>>
>> Yes, I completely agree. The user has requested a full merge and
>> sorted out all the physical and semantic conflicts. The mergeinfo is
>> meant to record the intent of the merge, as you correctly argued,
>> rather than to record exactly where the physical content changes were
>> made in the target branch in order to achieve the desired result [2].
>> Therefore the merge should be recorded, in the end, as a complete
>> merge, with no subtree mergeinfo needed.
>>
>> There are two or three things going on. (I'm going to be critical of
>> Subversion here.)
>>
>> 1. The user should always have the choice to record a subtree as
>> 'merged' or as 'not merged'. Subversion currently doesn't make this
>> choice easily available, and doesn't clearly report or document what
>> it's doing, in all the cases that can occur during a merge such as
>>
>>   - a conflict occurs
>>   - skipped because subtree is missing, obstructed, or still
>> conflicted from an earlier merge
>>   - subtree is switched
>>
>> and across different operations on the subtree, such as
>>
>>   - revert changes to subtree
>>   - copy/move/rename the subtree
>>
>> In some of these cases it records mergeinfo indicating 'merged', and
>> in other cases indicating 'not merged'.
>>
>> 2. Subtree mergeinfo was never designed to be an absolute indicator
>> that a subtree merge had been done. In other words, there was no
>> specific rule that a complete tree merge must result in no subtree
>> mergeinfo. After 1.5 was released and some work flows resulted in lots
>> of subtree mergeinfo (especially, I remember, copies added subtree
>> mergeinfo), there was a succession of refinements aimed at reducing
>> the number of nodes having subtree mergeinfo.
>>
>> When Subversion creates (or fails to elide) unnecessary subtree
>> mergeinfo, we classify that as suboptimal performance but not an
>> outright bug.
>>
>> In fact, the plan for eliding mergeinfo is not simply "always elide
>> any unnecessary explicit mergeinfo". In some cases it's more like
>> "elide unnecessary mergeinfo if we're touching that node anyway, but
>> don't touch other nodes just to elide their mergeinfo". In other
>> words, trying to minimize the number of changes to be committed. I
>> don't know the details of when we do what.
>>
>> 3. The Working Copy and its user interface doesn't keep track of what
>> merge(s) you have done, it just tracks the resulting mergeinfo
>> properties. As a consequence, for example, after doing a merge to the
>> root of the WC if you try to commit a subtree, it won't notice that
>> actually to commit the subtree along with the subtree's mergeinfo it
>> needs to put a mergeinfo property on the subtree.
>>
>> What you will find is that the merge implementation has not carefully
>> followed a consistent set of rules or a 'mental model'. There have
>> been rules and mental models but they have not been formally
>> identified and kept consistent. I'd love to be able to point you to
>> the rules as documented, but unfortunately can't. And there are still
>> cases where it does something that's clearly wrong or inconsistent.
>>
>> What to do?
>>
>> In the case you identified, I certainly agree it's bad behaviour, not
>> what we want. But it's not easy to know exactly which cases need
>> fixing -- or if "fixing" this case would make it inconsistent with
>> other cases -- without first cataloguing the existing behaviour over
>> all or most cases. If somebody wants to work on fixing this case,
>> that's fine, what I'm saying is I'm more interested in figuring out
>> the bigger solution.
>>
>> Pete, you seem to have a good grasp of this stuff. Would you be
>> willing to help? Either in a small way, anything from saying "please
>> just fix this case" upwards, or in a bigger way by helping to
>> catalogue the existing behaviour and decide what we should do about it
>> overall? No worries if not, but we do rely on those who have an
>> interest.
[...]
>
> Thank you very much for your email, and its articulation of the
> history and current state of the issue!

You're welcome.

> I am absolutely willing to help as much as I can.  My interests are
> guided by the only way I've used or plan to use Subversion: root-level
> branching and merging in single-revision checkouts.  I'm aware that
> Subversion is designed to handle vastly more complex uses; I have some
> understanding of that but little to no experience and my time budget
> for exploring there is limited.

Excellent.

> In your case #3 above, where a user commits in a subtree after
> initiating a root-level merge, I would think an appropriate behavior
> would be for Subversion to throw an error [... or warning ...]

Sure. The hard part is not deciding whether to throw an error or issue
a warning or commit with the mergeinfo that applies to the subtree;
nor implementing one of those options. The hard part is designing the
idea of "this working copy is now in a merged state", what operations
this state should affect (including commit), how and when it should
get into and out of this state, and how to present this state to the
user (in feedback notifications, status, etc.).

> For case #1 (subtree conflict), you're saying that for one user
> preference, merge resolution would be responsible for saying "Okay,
> there was this subtree merge conflict here, but the user is saying
> it's resolved as part of the merge, so I don't need explicit subtree
> mergeinfo any longer; I'll delete it."  And for the other preference,
> merge resolution would say "Okay, there was this subtree merge
> conflict here, and the user has decided to omit this subtree from the
> merge altogether; I'll keep the mergeinfo and mark it appropriately.
> [how?]"  I would expect the first situation to be vastly more common
> than the latter, but I appreciate that you want to handle both cases.

Yes. I agree the first situation (resolved as merged) would be vastly
more common. I'm just trying to say that the concept of being able to
have part of the tree recorded as "not merged" already exists, and the
problem is we don't make it clear to the user whether that outcome is
going to happen or has happened. We need clarity. A policy that that
shall never happen except through very explicit user request would be
one way to help achieve clarity.

> What currently happens is that the mergeinfo doesn't record anything
> for the current merge (it stays the same as the root mergeinfo was
> prior to initiating the merge).  If a later merge modifies a file in
> the subtree then it gets updated to be almost but not quite the same
> as[1] root mergeinfo, but not until then.

Ugh. :-)

> [1] See http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260,
> where the revisions recorded don't match the message about them.
>
> This leads me to believe that merge resolution is where the change is
> likely to belong to address the concern I have.  On the other hand,
> since in this situation it doesn't look like anything is prepared to
> do something useful with the mergeinfo that appeared, perhaps it's
> easier to stop it from appearing until the time when the other pieces
> are in place.  My level of ignorance regarding that statement is
> large, because I don't know Subversion internals or the ramifications
> of this outside the simple ways that I use the tool.
>
> If you have suggestions for how I could further help this issue along,
> please let me know.  And thanks again very much for your time.

It would help to catalogue the various cases. Maybe start with an
premise that a whole tree merge should not generate any subtree
mergeinfo and start finding the exceptions that currently occur.

Another way to help would be to think about how the client could
present the "WC is in a merged state" notion, and how that would
affect various operations. Just assume that we can implement it, and
imagine how it should behave in order to be useful. Is there a hard
dividing line between "is" and "is not" in a "merged" state for the
whole WC -- what if we *want* to merge subtrees separately? Does this
"state" need more degrees of subtlety in some other way too?

- Julian

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Tue, Mar 31, 2015 at 8:05 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Hello.
>
> Firstly I'd like to say thank you, Pete, for bringing up this issue
> and discussing it so clearly.
>
> I had a think about this the other day and chatted with the others on IRC [1].
>
> I picked this old email from this thread to reply to, as it's got me
> in the CC and is as good a one as any to reply to.
>
> Much of this has been said already, but here's my 'take' on the problem.
>
>
> On 2015-03-16, Pete Harlan wrote:
>> On 2015-03-14, Pete Harlan wrote:
>>> My expectation as a naive user is: I initiated a merge from the root
>>> of a branch (or trunk), I told svn to merge the root of another branch
>>> (or trunk), and I resolved all reported conflicts (however complex).
>>> Unless I've explicitly told svn otherwise, I expect svn to consider
>>> this a full merge, and not create separate mergeinfo for any interior
>>> nodes.
>
> Yes, I completely agree. The user has requested a full merge and
> sorted out all the physical and semantic conflicts. The mergeinfo is
> meant to record the intent of the merge, as you correctly argued,
> rather than to record exactly where the physical content changes were
> made in the target branch in order to achieve the desired result [2].
> Therefore the merge should be recorded, in the end, as a complete
> merge, with no subtree mergeinfo needed.
>
> There are two or three things going on. (I'm going to be critical of
> Subversion here.)
>
> 1. The user should always have the choice to record a subtree as
> 'merged' or as 'not merged'. Subversion currently doesn't make this
> choice easily available, and doesn't clearly report or document what
> it's doing, in all the cases that can occur during a merge such as
>
>   - a conflict occurs
>   - skipped because subtree is missing, obstructed, or still
> conflicted from an earlier merge
>   - subtree is switched
>
> and across different operations on the subtree, such as
>
>   - revert changes to subtree
>   - copy/move/rename the subtree
>
> In some of these cases it records mergeinfo indicating 'merged', and
> in other cases indicating 'not merged'.
>
> 2. Subtree mergeinfo was never designed to be an absolute indicator
> that a subtree merge had been done. In other words, there was no
> specific rule that a complete tree merge must result in no subtree
> mergeinfo. After 1.5 was released and some work flows resulted in lots
> of subtree mergeinfo (especially, I remember, copies added subtree
> mergeinfo), there was a succession of refinements aimed at reducing
> the number of nodes having subtree mergeinfo.
>
> When Subversion creates (or fails to elide) unnecessary subtree
> mergeinfo, we classify that as suboptimal performance but not an
> outright bug.
>
> In fact, the plan for eliding mergeinfo is not simply "always elide
> any unnecessary explicit mergeinfo". In some cases it's more like
> "elide unnecessary mergeinfo if we're touching that node anyway, but
> don't touch other nodes just to elide their mergeinfo". In other
> words, trying to minimize the number of changes to be committed. I
> don't know the details of when we do what.
>
> 3. The Working Copy and its user interface doesn't keep track of what
> merge(s) you have done, it just tracks the resulting mergeinfo
> properties. As a consequence, for example, after doing a merge to the
> root of the WC if you try to commit a subtree, it won't notice that
> actually to commit the subtree along with the subtree's mergeinfo it
> needs to put a mergeinfo property on the subtree.
>
> What you will find is that the merge implementation has not carefully
> followed a consistent set of rules or a 'mental model'. There have
> been rules and mental models but they have not been formally
> identified and kept consistent. I'd love to be able to point you to
> the rules as documented, but unfortunately can't. And there are still
> cases where it does something that's clearly wrong or inconsistent.
>
> What to do?
>
> In the case you identified, I certainly agree it's bad behaviour, not
> what we want. But it's not easy to know exactly which cases need
> fixing -- or if "fixing" this case would make it inconsistent with
> other cases -- without first cataloguing the existing behaviour over
> all or most cases. If somebody wants to work on fixing this case,
> that's fine, what I'm saying is I'm more interested in figuring out
> the bigger solution.
>
> Pete, you seem to have a good grasp of this stuff. Would you be
> willing to help? Either in a small way, anything from saying "please
> just fix this case" upwards, or in a bigger way by helping to
> catalogue the existing behaviour and decide what we should do about it
> overall? No worries if not, but we do rely on those who have an
> interest.
>
> - Julian
[...]
>
> [1] IRC log: http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-30#l74
>
> [2] I nearly said 'correct result' but, as you know, as far as
> Subversion is concerned a merge result is inherently subject to the
> user's judgement and cannot be called Right or Wrong.

Thank you very much for your email, and its articulation of the
history and current state of the issue!

I am absolutely willing to help as much as I can.  My interests are
guided by the only way I've used or plan to use Subversion: root-level
branching and merging in single-revision checkouts.  I'm aware that
Subversion is designed to handle vastly more complex uses; I have some
understanding of that but little to no experience and my time budget
for exploring there is limited.

In your case #3 above, where a user commits in a subtree after
initiating a root-level merge, I would think an appropriate behavior
would be for Subversion to throw an error, rather than trying to do
the strange thing that it seems that the user is now asking for.  Or
if an outright error isn't desired, at least, "You initiated the merge
at $path but you're now asking me to commit only $subpath; are you
sure? [y/N]".  And then confirm again if they say yes because they're
probably wrong ;-)

For case #1 (subtree conflict), you're saying that for one user
preference, merge resolution would be responsible for saying "Okay,
there was this subtree merge conflict here, but the user is saying
it's resolved as part of the merge, so I don't need explicit subtree
mergeinfo any longer; I'll delete it."  And for the other preference,
merge resolution would say "Okay, there was this subtree merge
conflict here, and the user has decided to omit this subtree from the
merge altogether; I'll keep the mergeinfo and mark it appropriately.
[how?]"  I would expect the first situation to be vastly more common
than the latter, but I appreciate that you want to handle both cases.

What currently happens is that the mergeinfo doesn't record anything
for the current merge (it stays the same as the root mergeinfo was
prior to initiating the merge).  If a later merge modifies a file in
the subtree then it gets updated to be almost but not quite the same
as[1] root mergeinfo, but not until then.

[1] See http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260,
where the revisions recorded don't match the message about them.

This leads me to believe that merge resolution is where the change is
likely to belong to address the concern I have.  On the other hand,
since in this situation it doesn't look like anything is prepared to
do something useful with the mergeinfo that appeared, perhaps it's
easier to stop it from appearing until the time when the other pieces
are in place.  My level of ignorance regarding that statement is
large, because I don't know Subversion internals or the ramifications
of this outside the simple ways that I use the tool.

If you have suggestions for how I could further help this issue along,
please let me know.  And thanks again very much for your time.

--Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Julian Foad <ju...@btopenworld.com>]

Hello.

Firstly I'd like to say thank you, Pete, for bringing up this issue
and discussing it so clearly.

I had a think about this the other day and chatted with the others on IRC [1].

I picked this old email from this thread to reply to, as it's got me
in the CC and is as good a one as any to reply to.

Much of this has been said already, but here's my 'take' on the problem.


On 2015-03-16, Pete Harlan wrote:
> On 2015-03-14, Pete Harlan wrote:
>> My expectation as a naive user is: I initiated a merge from the root
>> of a branch (or trunk), I told svn to merge the root of another branch
>> (or trunk), and I resolved all reported conflicts (however complex).
>> Unless I've explicitly told svn otherwise, I expect svn to consider
>> this a full merge, and not create separate mergeinfo for any interior
>> nodes.

Yes, I completely agree. The user has requested a full merge and
sorted out all the physical and semantic conflicts. The mergeinfo is
meant to record the intent of the merge, as you correctly argued,
rather than to record exactly where the physical content changes were
made in the target branch in order to achieve the desired result [2].
Therefore the merge should be recorded, in the end, as a complete
merge, with no subtree mergeinfo needed.

There are two or three things going on. (I'm going to be critical of
Subversion here.)

1. The user should always have the choice to record a subtree as
'merged' or as 'not merged'. Subversion currently doesn't make this
choice easily available, and doesn't clearly report or document what
it's doing, in all the cases that can occur during a merge such as

  - a conflict occurs
  - skipped because subtree is missing, obstructed, or still
conflicted from an earlier merge
  - subtree is switched

and across different operations on the subtree, such as

  - revert changes to subtree
  - copy/move/rename the subtree

In some of these cases it records mergeinfo indicating 'merged', and
in other cases indicating 'not merged'.

2. Subtree mergeinfo was never designed to be an absolute indicator
that a subtree merge had been done. In other words, there was no
specific rule that a complete tree merge must result in no subtree
mergeinfo. After 1.5 was released and some work flows resulted in lots
of subtree mergeinfo (especially, I remember, copies added subtree
mergeinfo), there was a succession of refinements aimed at reducing
the number of nodes having subtree mergeinfo.

When Subversion creates (or fails to elide) unnecessary subtree
mergeinfo, we classify that as suboptimal performance but not an
outright bug.

In fact, the plan for eliding mergeinfo is not simply "always elide
any unnecessary explicit mergeinfo". In some cases it's more like
"elide unnecessary mergeinfo if we're touching that node anyway, but
don't touch other nodes just to elide their mergeinfo". In other
words, trying to minimize the number of changes to be committed. I
don't know the details of when we do what.

3. The Working Copy and its user interface doesn't keep track of what
merge(s) you have done, it just tracks the resulting mergeinfo
properties. As a consequence, for example, after doing a merge to the
root of the WC if you try to commit a subtree, it won't notice that
actually to commit the subtree along with the subtree's mergeinfo it
needs to put a mergeinfo property on the subtree.

What you will find is that the merge implementation has not carefully
followed a consistent set of rules or a 'mental model'. There have
been rules and mental models but they have not been formally
identified and kept consistent. I'd love to be able to point you to
the rules as documented, but unfortunately can't. And there are still
cases where it does something that's clearly wrong or inconsistent.

What to do?

In the case you identified, I certainly agree it's bad behaviour, not
what we want. But it's not easy to know exactly which cases need
fixing -- or if "fixing" this case would make it inconsistent with
other cases -- without first cataloguing the existing behaviour over
all or most cases. If somebody wants to work on fixing this case,
that's fine, what I'm saying is I'm more interested in figuring out
the bigger solution.

Pete, you seem to have a good grasp of this stuff. Would you be
willing to help? Either in a small way, anything from saying "please
just fix this case" upwards, or in a bigger way by helping to
catalogue the existing behaviour and decide what we should do about it
overall? No worries if not, but we do rely on those who have an
interest.

- Julian


>> So I think it would be worth updating "svn resolve" to, by default,
>> take action to trust the user and mark this as a full resolution.  If
>> the user needs to take an extra step or add a new parameter to get
>> that effect, would that not feel like a regression compared with 1.7?
>
> A colleague argued that creating the mergeinfo for a subtree in this
> case (root->root merge) is a simple bug because mergeinfo says what
> inputs were considered to come up with the result, not just those that
> were used.
>
> 1. If the resulting mergeinfo is the same as for root then it's
> unnecessary, so the bug is that it is explicitly listed at all.
>
> 2. If the resulting mergeinfo is different than then root one then
> it's incorrect, because it's claiming that the subtree working copy
> represents the merge of a different set of branches and revisions than
> the root working copy it's included within.
>
> In other words, it would always be wrong for a merge to introduce
> explicit mergeinfo for a subtree of the merge point.
>
> This implies that the fix wouldn't be to change how resolve works, it
> would be for "svn merge" to not create the property on the subtree in
> the first place.
>
> What do you think?
>
> Thanks,
> Pete

[1] IRC log: http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-30#l74

[2] I nearly said 'correct result' but, as you know, as far as
Subversion is concerned a merge result is inherently subject to the
user's judgement and cannot be called Right or Wrong.

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan <pc...@gmail.com> wrote:
> As you pointed out, my original report erroneously focused on
> svn:mergeinfo appearing, when the real issue is that the new
> svn:mergeinfo doesn't disappear (still) when the user marks the
> conflict resolved.  (And I haven't found a way to remove it besides
> propdel; "svn merge --record-only ^/trunk" has no effect afaict.)
>
> My expectation as a naive user is: I initiated a merge from the root
> of a branch (or trunk), I told svn to merge the root of another branch
> (or trunk), and I resolved all reported conflicts (however complex).
> Unless I've explicitly told svn otherwise, I expect svn to consider
> this a full merge, and not create separate mergeinfo for any interior
> nodes.
>
> So I think it would be worth updating "svn resolve" to, by default,
> take action to trust the user and mark this as a full resolution.  If
> the user needs to take an extra step or add a new parameter to get
> that effect, would that not feel like a regression compared with 1.7?

A colleague argued that creating the mergeinfo for a subtree in this
case (root->root merge) is a simple bug because mergeinfo says what
inputs were considered to come up with the result, not just those that
were used.

1. If the resulting mergeinfo is the same as for root then it's
unnecessary, so the bug is that it is explicitly listed at all.

2. If the resulting mergeinfo is different than then root one then
it's incorrect, because it's claiming that the subtree working copy
represents the merge of a different set of branches and revisions than
the root working copy it's included within.

In other words, it would always be wrong for a merge to introduce
explicit mergeinfo for a subtree of the merge point.

This implies that the fix wouldn't be to change how resolve works, it
would be for "svn merge" to not create the property on the subtree in
the first place.

What do you think?

Thanks,
Pete

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

On Sat, Mar 14, 2015 at 7:45 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Looking further (after turning your test in a regression test), I think this shows another problem. The conflict is on 'dir', not really on file.
>
> But (for legacy reasons) we somehow think that conflicting directory adds are something that we can usually just ignore (because there is no real difference between directories). So the merge of dir is somehow auto resolved, but then still conflicts via file.txt.
>
> If file is not added because there is a conflict on 'dir' that mergeinfo should really be on 'dir' instead of 'dir/file.txt'...
>
> Where also the tree conflict is stored.
>
>
> As the merge determined that 'file.txt' in the working copy, and 'file.txt' as merged are completely different nodes, it should have never changed the unrelated 'file.txt'.
>
> I think this partially answers your question... and shows a real problem.
> (This problem is fixed in r1666690)
>
> The problem is now how would we resolve this in the future:
>
> We still have a tree conflict. One directory with files obstructing another directory with files...
> Or as 'svn info' describes it:
> [[
> Tree conflict: local dir obstruction, incoming dir add upon merge
>    Source  left: (none) ^/trunk/dir@1
>    Source right: (dir) ^/trunk/dir@4
> ]]
>
> I can see three ways to resolve from this situation:
> * Accept whatever is currently here, as the merged situation.  (accept mine-full ?)
> This should just record the merge as happened and then elide with the parent.
> (I thinks this matches your expectation. But it isn't implemented yet)
>
> * Accept that what is merged in should be kept. (accept theirs-full ?)
> This should delete what is currently there. (svn rm --force dir).
> Perform something like 'svn cp ^/trunk/dir@4 dir'
> (And then record the merge as happened, by not altering any mergeinfo)
> Also not implemented yet... and depending on the current working copy state possibly dangerous.
>
> * Just delete the tree conflict, and allow the user to apply his own changes
> This is what currently happens with 'accept working'.
>
> I'm not sure what the mergeinfo behavior in this state should be. I just fixed that we at least properly record the mergeinfo on 'dir', but it is possible that not recording mergeinfo is a better option here.
>
> With these three options for resolving I don't see a case where recording the mergeinfo makes complete sense for this particular testcase... accept for allowing the merge to continue where it stopped.
>
> In this specific conflict that can never happen, because dir never received actual changes in either branch or trunk... But in real working copies there might be hundreds of changes on both branches.
>
>         Bert

Thank you for the analysis, and for your change!  I agree that this is
an improvement: now the directory that is conflicted gets the
svn:mergeinfo property, not each of its contents.

As you pointed out, my original report erroneously focused on
svn:mergeinfo appearing, when the real issue is that the new
svn:mergeinfo doesn't disappear (still) when the user marks the
conflict resolved.  (And I haven't found a way to remove it besides
propdel; "svn merge --record-only ^/trunk" has no effect afaict.)

My expectation as a naive user is: I initiated a merge from the root
of a branch (or trunk), I told svn to merge the root of another branch
(or trunk), and I resolved all reported conflicts (however complex).
Unless I've explicitly told svn otherwise, I expect svn to consider
this a full merge, and not create separate mergeinfo for any interior
nodes.

So I think it would be worth updating "svn resolve" to, by default,
take action to trust the user and mark this as a full resolution.  If
the user needs to take an extra step or add a new parameter to get
that effect, would that not feel like a regression compared with 1.7?

Thanks,

Pete

RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: zaterdag 14 maart 2015 13:06
> To: 'Pete Harlan'
> Cc: 'subversion'; pburba@collab.net; 'Julian Foad'
> Subject: RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
> 
> [CC-ing two Subversion developers that might have more input on this... I'm not
> a merge expert :-)]
> 
> > -----Original Message-----
> > From: Pete Harlan [mailto:pchpublic88@gmail.com]
> > Sent: zaterdag 14 maart 2015 02:45
> > To: Bert Huijben
> > Cc: subversion
> > Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
> >
> > 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 -
> 
> This mergeinformation on 'dir/file' is actually a copy of what was on trunk
> before this merge started, containing everything except the merge that was
> skipped.

Looking further (after turning your test in a regression test), I think this shows another problem. The conflict is on 'dir', not really on file.

But (for legacy reasons) we somehow think that conflicting directory adds are something that we can usually just ignore (because there is no real difference between directories). So the merge of dir is somehow auto resolved, but then still conflicts via file.txt.

If file is not added because there is a conflict on 'dir' that mergeinfo should really be on 'dir' instead of 'dir/file.txt'... 

Where also the tree conflict is stored.


As the merge determined that 'file.txt' in the working copy, and 'file.txt' as merged are completely different nodes, it should have never changed the unrelated 'file.txt'.

I think this partially answers your question... and shows a real problem.
(This problem is fixed in r1666690)

The problem is now how would we resolve this in the future:

We still have a tree conflict. One directory with files obstructing another directory with files...
Or as 'svn info' describes it:
[[
Tree conflict: local dir obstruction, incoming dir add upon merge
   Source  left: (none) ^/trunk/dir@1
   Source right: (dir) ^/trunk/dir@4
]]

I can see three ways to resolve from this situation:
* Accept whatever is currently here, as the merged situation.  (accept mine-full ?)
This should just record the merge as happened and then elide with the parent.
(I thinks this matches your expectation. But it isn't implemented yet)

* Accept that what is merged in should be kept. (accept theirs-full ?)
This should delete what is currently there. (svn rm --force dir).
Perform something like 'svn cp ^/trunk/dir@4 dir'
(And then record the merge as happened, by not altering any mergeinfo)
Also not implemented yet... and depending on the current working copy state possibly dangerous.

* Just delete the tree conflict, and allow the user to apply his own changes
This is what currently happens with 'accept working'.

I'm not sure what the mergeinfo behavior in this state should be. I just fixed that we at least properly record the mergeinfo on 'dir', but it is possible that not recording mergeinfo is a better option here.

With these three options for resolving I don't see a case where recording the mergeinfo makes complete sense for this particular testcase... accept for allowing the merge to continue where it stopped.

In this specific conflict that can never happen, because dir never received actual changes in either branch or trunk... But in real working copies there might be hundreds of changes on both branches.

	Bert

RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Bert Huijben <be...@qqmail.nl>]

[CC-ing two Subversion developers that might have more input on this... I'm not a merge expert :-)]

> -----Original Message-----
> From: Pete Harlan [mailto:pchpublic88@gmail.com]
> Sent: zaterdag 14 maart 2015 02:45
> To: Bert Huijben
> Cc: subversion
> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
> 
> 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 -

This mergeinformation on 'dir/file' is actually a copy of what was on trunk before this merge started, containing everything except the merge that was skipped.

> % svn resolve --accept=working dir dir/file.txt
> Resolved conflicted state of 'dir'

Ack. This removes the conflict state to allow the conflict.

If you would now (or after the conflict) run the same merge with --record-only the mergeinfo on parent and ancestor would be the same again.

% svn merge -c 2-4 ^/trunk --record-only

This tells Subversion that you performed all things to make the merge match the original revisions.

This has the effect of 'eliding' the mergeinfo on the file. (Something which you and probably every other user would probably call 'removing the svn:mergeinfo property' from the file... Which is what happens if the mergeinfo matches that of the ancestor)

I think it would be useful if the conflict resolver had an option to do this automatically for you, but I don't think we currently implement any resolving of tree conflicts at merge. (It is on our feature wish list, but it is very hard to determine what a user should/could do in each of the conflict situation)

> % 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.

You performed a multi revision merge and some of the changes were not applied to the target. R2 might have added the file, while r3 and r4 might have other interesting changes for this file.
(Your script knows... but Subversion doesn't... While merging It just sees the merge as a range with a start and end-state)

Why would you request that we just ignore those other changes by recording that everything was merged into your working copy?
(The fact that we did this in 1.7 is what we call a bug).

Losing valuable information during merges is one of the reasons we introduced tree conflicts in 1.6, and improved their detection in later versions.

> 
> 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?

Yes.
See the record only merge I recommended above.
(Just setting the property yourself doesn't trigger the elide code. Setting it using record only does this)

> 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.)

These values surprise me. Especially 3-6. (I would have expected 2-6 (= the elide), or 5-6 (whatever was not merged first))

> 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?

It is in our current implementation identical to that record only merge. Future merge improvements might work better if you created one 'file.txt' and merged that directly, but I don't see any problems in any versions of Subversion that exist today. (Including the upcoming 1.9)

> 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.

I agree that it would be nice to do this automatically as one of the options during conflict resolving.

But the 'choose working' option you used here, is in almost every case keep the working copy as it is now and only remove the marker. Perhaps it would be the logical thing to do on 'mine-conflict' or 'theirs-conflict' for this particular type of conflict (Not sure which. I leave that to the merge experts).

Note that the tree conflict has exactly this information stored to do this operation for you (See 'svn info' on your conflicted file)... We just haven't any resolver strategies on merge implemented yet.


> 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?

I hope I explained a few more things here.

	Bert
> 
> Thank you for your time.
> 
> Pete
> 
> On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben <be...@qqmail.nl> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pete Harlan [mailto:pchpublic88@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
> >

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

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 <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Pete Harlan [mailto:pchpublic88@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
>

RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Pete Harlan [mailto:pchpublic88@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

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

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.

Lack of understanding this issue is preventing us from moving past
1.7; any help would be most appreciated.

Thank you,

--Pete


On Thu, Mar 12, 2015 at 3:50 PM, Pete Harlan <pc...@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?
>
> Thanks,
>
> --Pete
>
> On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan <pc...@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,
>>
>> --Pete
>>
>> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben <be...@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.
>>>
>>> Bert
>>> Sent from Windows Mail
>>>
>>> From: Pete Harlan
>>> Sent: ‎Wednesday‎, ‎March‎ ‎11‎, ‎2015 ‎11‎:‎16‎ ‎PM
>>> To: 'subversion'
>>>
>>> Hi,
>>>
>>> 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:
>>>
>>> Layout:
>>>
>>> /trunk
>>> /branches/branch
>>>
>>> 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 '.':
>>>   svn:mergeinfo
>>>     /trunk:2-4
>>> Properties on 'dir/file.txt':
>>>   svn:mergeinfo
>>>
>>> %
>>>
>>> Expected result is that no svn:mergeinfo property would appear on
>>> dir/file.txt.  Is this a bug?  A known bug?
>>>
>>> Thanks,
>>> Pete
>>>
>>> Script to reproduce (run as "script.sh /path/to/svn"):
>>>
>>> #!/bin/bash
>>> #
>>> # 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
>>>
>>> SERVER_DIR=server
>>> CLIENT_DIR=client
>>>
>>> if [ $# != 1 ]; then
>>>     echo "usage: $0 <path to svn>"
>>>     exit
>>> fi
>>>
>>> SVN=$1
>>> SVNADMIN="$(dirname $SVN)/svnadmin"
>>>
>>> SERVER_URL="file:///$PWD/$SERVER_DIR"
>>>
>>> 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
>>> else
>>>     echo 'Test failed!'
>>>     echo 'Expected output:'
>>>     cat expected.out
>>>     echo 'Actual output:'
>>>     cat actual.out
>>>     exit 1
>>> fi

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

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?

Thanks,

--Pete

On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan <pc...@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,
>
> --Pete
>
> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben <be...@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.
>>
>> Bert
>> Sent from Windows Mail
>>
>> From: Pete Harlan
>> Sent: ‎Wednesday‎, ‎March‎ ‎11‎, ‎2015 ‎11‎:‎16‎ ‎PM
>> To: 'subversion'
>>
>> Hi,
>>
>> 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:
>>
>> Layout:
>>
>> /trunk
>> /branches/branch
>>
>> 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 '.':
>>   svn:mergeinfo
>>     /trunk:2-4
>> Properties on 'dir/file.txt':
>>   svn:mergeinfo
>>
>> %
>>
>> Expected result is that no svn:mergeinfo property would appear on
>> dir/file.txt.  Is this a bug?  A known bug?
>>
>> Thanks,
>> Pete
>>
>> Script to reproduce (run as "script.sh /path/to/svn"):
>>
>> #!/bin/bash
>> #
>> # 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
>>
>> SERVER_DIR=server
>> CLIENT_DIR=client
>>
>> if [ $# != 1 ]; then
>>     echo "usage: $0 <path to svn>"
>>     exit
>> fi
>>
>> SVN=$1
>> SVNADMIN="$(dirname $SVN)/svnadmin"
>>
>> SERVER_URL="file:///$PWD/$SERVER_DIR"
>>
>> 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
>> else
>>     echo 'Test failed!'
>>     echo 'Expected output:'
>>     cat expected.out
>>     echo 'Actual output:'
>>     cat actual.out
>>     exit 1
>> fi

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan <pc...@gmail.com>]

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,

--Pete

On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben <be...@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.
>
> Bert
> Sent from Windows Mail
>
> From: Pete Harlan
> Sent: ‎Wednesday‎, ‎March‎ ‎11‎, ‎2015 ‎11‎:‎16‎ ‎PM
> To: 'subversion'
>
> Hi,
>
> 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:
>
> Layout:
>
> /trunk
> /branches/branch
>
> 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 '.':
>   svn:mergeinfo
>     /trunk:2-4
> Properties on 'dir/file.txt':
>   svn:mergeinfo
>
> %
>
> Expected result is that no svn:mergeinfo property would appear on
> dir/file.txt.  Is this a bug?  A known bug?
>
> Thanks,
> Pete
>
> Script to reproduce (run as "script.sh /path/to/svn"):
>
> #!/bin/bash
> #
> # 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
>
> SERVER_DIR=server
> CLIENT_DIR=client
>
> if [ $# != 1 ]; then
>     echo "usage: $0 <path to svn>"
>     exit
> fi
>
> SVN=$1
> SVNADMIN="$(dirname $SVN)/svnadmin"
>
> SERVER_URL="file:///$PWD/$SERVER_DIR"
>
> 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
> else
>     echo 'Test failed!'
>     echo 'Expected output:'
>     cat expected.out
>     echo 'Actual output:'
>     cat actual.out
>     exit 1
> fi

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Bert Huijben <be...@qqmail.nl>]

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.




Bert


Sent from Windows Mail





From: Pete Harlan
Sent: ‎Wednesday‎, ‎March‎ ‎11‎, ‎2015 ‎11‎:‎16‎ ‎PM
To: 'subversion'





Hi,

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:

Layout:

/trunk
/branches/branch

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 '.':
  svn:mergeinfo
    /trunk:2-4
Properties on 'dir/file.txt':
  svn:mergeinfo

%

Expected result is that no svn:mergeinfo property would appear on
dir/file.txt.  Is this a bug?  A known bug?

Thanks,
Pete

Script to reproduce (run as "script.sh /path/to/svn"):

#!/bin/bash
#
# 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

SERVER_DIR=server
CLIENT_DIR=client

if [ $# != 1 ]; then
    echo "usage: $0 <path to svn>"
    exit
fi

SVN=$1
SVNADMIN="$(dirname $SVN)/svnadmin"

SERVER_URL="file:///$PWD/$SERVER_DIR"

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
else
    echo 'Test failed!'
    echo 'Expected output:'
    cat expected.out
    echo 'Actual output:'
    cat actual.out
    exit 1
fi