You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2011/10/27 14:11:22 UTC
Status of the 'showing-merge-info' branch
At the moment, on the 'showing-merge-info' branch, I have several
things going on; here are some of them.
SHOWING SUMMARIZED MERGEINFO
[[[
$ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
[...]
Revision range(s) recorded as merged:
to target path '.':
875965,875968,...,1151036 (477 ranges) from same relative path
to target path 'CHANGES':
875962-1130989 from same relative path
to target path 'get-deps.sh':
878590,878607,...,1126007 (7 ranges) from same relative path
to target path 'subversion/include/private/svn_repos_private.h':
878590,878607,...,1126007 (17 ranges) from same relative path
to target path 'subversion/libsvn_fs_fs/rep-cache.c':
875965,875968,...,1126007 (456 ranges) from same relative path
to target path 'subversion/tests/cmdline/merge_tests.py':
875965,875968,...,1126007 (432 ranges) from same relative path
953878,1146121 from source path
'subversion/tests/cmdline/merge_reintegrate_tests.py'
to target path 'subversion/tests/cmdline/svntest/main.py':
991972 from source path
'subversion/tests/cmdline/svntest/sandbox.py'
875965,875968,...,1126007 (441 ranges) from same relative path
]]]
I want "svn mergeinfo" to show a high-level summary of the situation.
This currently shows the parts of the mergeinfo on the target that
pertain to the source branch, including subtrees, in a summarized
form. It could be summarized better; for instance, group together
several target paths that all have the same source ranges merged to
them.
After that it currently goes on to print the "merged" and then the
"eligible" revisions as lists of individual "operative" (non-empty)
changes, with a (currently fake) classification of each change as a
"merge" or an "original commit". That's more because I'm interested in
the ability to do such classification, and not that I would
necessarily want to show that in the "mergeinfo" command output.
IDENTIFYING BRANCH ROOTS
[[[
$ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
Branch marker: 'subversion-source-tree' (found on both source and target)
[...]
$ svn mergeinfo ^/subversion/trunk ^/subversion/branches
svn: E195016: Source branch marker is 'subversion-source-tree' but
target has no branch marker
$ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
svn: E195016: Source and target are the same branch
]]]
This looks for a branch root marker property on the specified
directory. The property name would be 'svn:branch-root' and the value
would be a string that (more or less uniquely) identifies the
'project' (for want of a better word) of which this is a branch.
Currently, just for testing, the property it looks for is the first
ten characters of 'svn:ignore', which tends to work moderately well
for ad-hoc testing against our own source tree because it exists and
starts with 'ChangeLog*' in the root of every branch and (I guess)
nowhere else.
IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
[[[
$ svn mergeinfo
Assuming source branch is copied-from source of target branch. ###
target is implicit '.'
[...]
Source branch: ^/subversion/trunk (r1189704)
Target branch: ^/subversion/branches/showing-merge-info (working copy)
[...]
]]]
At the moment this only looks for the copied-from branch, which is not
good enough; if we do this at all then we need a way to . Stefan also
suggested it should only select a source automatically when it finds a
branch root marker, as that means someone has deliberately enabled the
feature.
MAKING MERGE EXPLAIN WHAT IT'S DOING
[[[
$ svn merge ^/subversion/trunk
Sync merge from '^/subversion/trunk' into '.' (a working copy of
'^/subversion/branches/showing-merge-info')
[... and maybe a summary of the revision ranges it's looking to pull in ...]
$ svn merge --reintegrate ^/subversion/branches/showing-merge-info
Reintegrate merge from '^/subversion/branches/showing-merge-info' into
'.' (a working copy of '^/subversion/branches/trunk')
The reintegrate merge will be equivalent to:
merge ^/subversion/trunk@1188748
^/subversion/branches/showing-merge-info@1189710 .
[...]
]]]
I've only just started with this and haven't checked all of this in.
We say that 'reintegrate' does a two-URL merge, but in wanting to make
it print what it's about to do I notice that the implementation
doesn't seem to call the two-URL merge code at all. I want to change
that and have the two phases completely separated: first the client
should figure out what merge it will do, and print that, then call the
two-URL merge code to actually do it.
Comments appreciated.
- Julian
Re: Status of the 'showing-merge-info' branch
Posted by Daniel Shahaf <da...@elego.de>.
Johan Corveleyn wrote on Fri, Oct 28, 2011 at 10:53:43 +0200:
> On Fri, Oct 28, 2011 at 10:21 AM, Daniel Shahaf <da...@elego.de> wrote:
> > Johan Corveleyn wrote on Fri, Oct 28, 2011 at 09:38:57 +0200:
> >> On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <da...@elego.de> wrote:
> >> > Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
> >> >> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
> >> >> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
> >> >> [...]
> >> >> >> IDENTIFYING BRANCH ROOTS
> >> >> >>
> >> >> >> [[[
> >> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> >> >> >> Branch marker: 'subversion-source-tree' (found on both source and target)
> >> >> >> [...]
> >> >> >>
> >> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
> >> >> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
> >> >> >> target has no branch marker
> >> >> >>
> >> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
> >> >> >> svn: E195016: Source and target are the same branch
> >> >> >> ]]]
> >> >> >>
> >> >> >> This looks for a branch root marker property on the specified
> >> >> >> directory. The property name would be 'svn:branch-root' and the value
> >> >> >> would be a string that (more or less uniquely) identifies the
> >> >> >> 'project' (for want of a better word) of which this is a branch.
> >> >> >> Currently, just for testing, the property it looks for is the first
> >> >> >> ten characters of 'svn:ignore', which tends to work moderately well
> >> >> >> for ad-hoc testing against our own source tree because it exists and
> >> >> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
> >> >> >> nowhere else.
> >> >> >
> >> >> >
> >> >> > This feature concerns me the most. I assume we are not proposing to add
> >> >> > this marker just for this one subcommand? I would like to see the big
> >> >> > picture of what we would do this marker so we can discuss its format and its
> >> >> > ramifications.
> >> >>
> >> >> I agree with this. A branch-roots feature can be very useful in a lot
> >> >> of contexts, and I'd like it to be carefully designed to address some
> >> >> shortcomings in branching/merging (and potentially tagging as well).
> >> >>
> >> >> For instance, it'd be nice if you could refer to the "current branch
> >> >> root" at the command line, or in externals definitions (externals
> >> >> relative to the branch root), or even in viewspec files
> >> >> (svn-viewspec.py). Or if you could say:
> >> >>
> >> >> svn merge --reintegrate branch:showing-merge-info
> >> >>
> >> >> which would look for the branch-root called 'showing-merge-info', part
> >> >> of the same 'branch-marker-space'. Or something like that (just
> >> >> throwing ideas in the air).
> >> >>
> >> >> Or:
> >> >>
> >> >> svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
> >> >>
> >> >> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
> >> >> 'namespace').
> >> >
> >> > Quick observation: you're asking the question "Where does the branch
> >> > named %s live" (and I consider tags a special case of branches for the
> >> > purposes of avoiding having to invent terminology at 2am), Julian is
> >> > asking the question "What branch is URL %s member of?". These two
> >> > questions don't seem directly related, my first hunch was that they're
> >> > quite opposite.
> >>
> >> Hm, indeed it's not the same question.Except if you structure your
> >> branches in such a way that it is (which is the case in our
> >> environment): all branches of branch-marker "MyApp" are put in
> >> ^/branches/MyApp (same for tags). So we effectively use the branches'
> >> parent dir as the "branch-marker" ... or something like that :-).
> >>
> >> Maybe "branch-context" is a better name than "branch-marker"?
> >>
> >> Thinking further about it, I think it makes some sense to establish a
> >> link between the branch-context, and the place where the branches
> >> live. For one thing, it helps to make sure that there are no name
> >> collisions between branches within the same branch-context. And people
> >> using SVN are quite used to the fact that branches/tags are part of
> >> the directory structure.
> >>
> >> OTOH, maybe people want to get rid of the fact that branches/tags are
> >> related to directories in the repository, and may want to ignore that
> >> a branch is located at a particular path. And if you move
> >> branches/tags around, you may want the branch-context to stay the same
> >> ... I really don't know, I haven't thought too deeply about this.
> >
> > Not sure what you're saying.
> >
> >
> > I don't want to disallow people from using branch patterns such as
> >
> > ^/branches/2010/my-abacus-branch
> > ^/branches/2011/my-calc-branch
> > ^/branches/2012/my-ALU-branch
> > (point being the existence of intermediate dirs)
> >
> > , so identifying branches by their path-wise parent would be
> > insufficiently generic.
>
> Yes, you're right. We have this situation as well. Maybe the
> "branch-context directory" needs its own marker. For a structure such
> as:
>
> ^/branches/MyApp/releases/2010/20101122
> ^/branches/MyApp/releases/2010/20101220
> ^/branches/MyApp/releases/2011/...
> ^/branches/MyApp/features/my-abacus
> ....
> ^/branches/YourApp/releases/2011/...
> ^/branches/YourApp/features/...
>
> where MyApp and YourApp are "branch-contexts", and "20101122",
> "my-abacus", etc. are branch-roots. If the ^/branches/MyApp and
> ^/branches/YourApp directories are marked somehow, you could travel
> upward from 20101122 to see that it belongs to the MyApp
> branch-context.
>
> MyApp and YourApp are two applications that are based on largely the
> same source code (so they come from the same trunk), they just have
> different front-ends, flavors, main-functions, ... and a different
> release schedule.
>
> > And if you're talking about identifying branches by their line-of-history
> > parent, aka by their node origin, see Trent Nelson's post a few weeks ago.
>
> Yes, that was also an interesting post. Though I'm not sure if solely
> identifying them by their line-of-history ancestry is sufficient (see
> the example above: branches from MyApp and YourApp come from the same
> trunk, but maybe you want to keep the branches apart ...). I don't
> know.
In Trent's framework I think you can detach such forks by editing rN's
revprops and recomputing the revprops for the remainder of the history.
I'm not sure if it immediately facilitates spoons[1], but I suppose that
could be added if the revprop told the code to pretend a copyfrom
relation existed where in the FS backend it doesn't.
[1] invented term meaning "a single line of history that has two parents"
--
(probably still biased)
Re: Status of the 'showing-merge-info' branch
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Oct 28, 2011 at 10:21 AM, Daniel Shahaf <da...@elego.de> wrote:
> Johan Corveleyn wrote on Fri, Oct 28, 2011 at 09:38:57 +0200:
>> On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <da...@elego.de> wrote:
>> > Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
>> >> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
>> >> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
>> >> [...]
>> >> >> IDENTIFYING BRANCH ROOTS
>> >> >>
>> >> >> [[[
>> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> >> >> Branch marker: 'subversion-source-tree' (found on both source and target)
>> >> >> [...]
>> >> >>
>> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
>> >> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
>> >> >> target has no branch marker
>> >> >>
>> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
>> >> >> svn: E195016: Source and target are the same branch
>> >> >> ]]]
>> >> >>
>> >> >> This looks for a branch root marker property on the specified
>> >> >> directory. The property name would be 'svn:branch-root' and the value
>> >> >> would be a string that (more or less uniquely) identifies the
>> >> >> 'project' (for want of a better word) of which this is a branch.
>> >> >> Currently, just for testing, the property it looks for is the first
>> >> >> ten characters of 'svn:ignore', which tends to work moderately well
>> >> >> for ad-hoc testing against our own source tree because it exists and
>> >> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> >> >> nowhere else.
>> >> >
>> >> >
>> >> > This feature concerns me the most. I assume we are not proposing to add
>> >> > this marker just for this one subcommand? I would like to see the big
>> >> > picture of what we would do this marker so we can discuss its format and its
>> >> > ramifications.
>> >>
>> >> I agree with this. A branch-roots feature can be very useful in a lot
>> >> of contexts, and I'd like it to be carefully designed to address some
>> >> shortcomings in branching/merging (and potentially tagging as well).
>> >>
>> >> For instance, it'd be nice if you could refer to the "current branch
>> >> root" at the command line, or in externals definitions (externals
>> >> relative to the branch root), or even in viewspec files
>> >> (svn-viewspec.py). Or if you could say:
>> >>
>> >> svn merge --reintegrate branch:showing-merge-info
>> >>
>> >> which would look for the branch-root called 'showing-merge-info', part
>> >> of the same 'branch-marker-space'. Or something like that (just
>> >> throwing ideas in the air).
>> >>
>> >> Or:
>> >>
>> >> svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
>> >>
>> >> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
>> >> 'namespace').
>> >
>> > Quick observation: you're asking the question "Where does the branch
>> > named %s live" (and I consider tags a special case of branches for the
>> > purposes of avoiding having to invent terminology at 2am), Julian is
>> > asking the question "What branch is URL %s member of?". These two
>> > questions don't seem directly related, my first hunch was that they're
>> > quite opposite.
>>
>> Hm, indeed it's not the same question.Except if you structure your
>> branches in such a way that it is (which is the case in our
>> environment): all branches of branch-marker "MyApp" are put in
>> ^/branches/MyApp (same for tags). So we effectively use the branches'
>> parent dir as the "branch-marker" ... or something like that :-).
>>
>> Maybe "branch-context" is a better name than "branch-marker"?
>>
>> Thinking further about it, I think it makes some sense to establish a
>> link between the branch-context, and the place where the branches
>> live. For one thing, it helps to make sure that there are no name
>> collisions between branches within the same branch-context. And people
>> using SVN are quite used to the fact that branches/tags are part of
>> the directory structure.
>>
>> OTOH, maybe people want to get rid of the fact that branches/tags are
>> related to directories in the repository, and may want to ignore that
>> a branch is located at a particular path. And if you move
>> branches/tags around, you may want the branch-context to stay the same
>> ... I really don't know, I haven't thought too deeply about this.
>
> Not sure what you're saying.
>
>
> I don't want to disallow people from using branch patterns such as
>
> ^/branches/2010/my-abacus-branch
> ^/branches/2011/my-calc-branch
> ^/branches/2012/my-ALU-branch
> (point being the existence of intermediate dirs)
>
> , so identifying branches by their path-wise parent would be
> insufficiently generic.
Yes, you're right. We have this situation as well. Maybe the
"branch-context directory" needs its own marker. For a structure such
as:
^/branches/MyApp/releases/2010/20101122
^/branches/MyApp/releases/2010/20101220
^/branches/MyApp/releases/2011/...
^/branches/MyApp/features/my-abacus
....
^/branches/YourApp/releases/2011/...
^/branches/YourApp/features/...
where MyApp and YourApp are "branch-contexts", and "20101122",
"my-abacus", etc. are branch-roots. If the ^/branches/MyApp and
^/branches/YourApp directories are marked somehow, you could travel
upward from 20101122 to see that it belongs to the MyApp
branch-context.
MyApp and YourApp are two applications that are based on largely the
same source code (so they come from the same trunk), they just have
different front-ends, flavors, main-functions, ... and a different
release schedule.
> And if you're talking about identifying branches by their line-of-history
> parent, aka by their node origin, see Trent Nelson's post a few weeks ago.
Yes, that was also an interesting post. Though I'm not sure if solely
identifying them by their line-of-history ancestry is sufficient (see
the example above: branches from MyApp and YourApp come from the same
trunk, but maybe you want to keep the branches apart ...). I don't
know.
--
Johan
Re: Status of the 'showing-merge-info' branch
Posted by Daniel Shahaf <da...@elego.de>.
Johan Corveleyn wrote on Fri, Oct 28, 2011 at 09:38:57 +0200:
> On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <da...@elego.de> wrote:
> > Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
> >> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
> >> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
> >> [...]
> >> >> IDENTIFYING BRANCH ROOTS
> >> >>
> >> >> [[[
> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> >> >> Branch marker: 'subversion-source-tree' (found on both source and target)
> >> >> [...]
> >> >>
> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
> >> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
> >> >> target has no branch marker
> >> >>
> >> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
> >> >> svn: E195016: Source and target are the same branch
> >> >> ]]]
> >> >>
> >> >> This looks for a branch root marker property on the specified
> >> >> directory. The property name would be 'svn:branch-root' and the value
> >> >> would be a string that (more or less uniquely) identifies the
> >> >> 'project' (for want of a better word) of which this is a branch.
> >> >> Currently, just for testing, the property it looks for is the first
> >> >> ten characters of 'svn:ignore', which tends to work moderately well
> >> >> for ad-hoc testing against our own source tree because it exists and
> >> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
> >> >> nowhere else.
> >> >
> >> >
> >> > This feature concerns me the most. I assume we are not proposing to add
> >> > this marker just for this one subcommand? I would like to see the big
> >> > picture of what we would do this marker so we can discuss its format and its
> >> > ramifications.
> >>
> >> I agree with this. A branch-roots feature can be very useful in a lot
> >> of contexts, and I'd like it to be carefully designed to address some
> >> shortcomings in branching/merging (and potentially tagging as well).
> >>
> >> For instance, it'd be nice if you could refer to the "current branch
> >> root" at the command line, or in externals definitions (externals
> >> relative to the branch root), or even in viewspec files
> >> (svn-viewspec.py). Or if you could say:
> >>
> >> svn merge --reintegrate branch:showing-merge-info
> >>
> >> which would look for the branch-root called 'showing-merge-info', part
> >> of the same 'branch-marker-space'. Or something like that (just
> >> throwing ideas in the air).
> >>
> >> Or:
> >>
> >> svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
> >>
> >> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
> >> 'namespace').
> >
> > Quick observation: you're asking the question "Where does the branch
> > named %s live" (and I consider tags a special case of branches for the
> > purposes of avoiding having to invent terminology at 2am), Julian is
> > asking the question "What branch is URL %s member of?". These two
> > questions don't seem directly related, my first hunch was that they're
> > quite opposite.
>
> Hm, indeed it's not the same question.Except if you structure your
> branches in such a way that it is (which is the case in our
> environment): all branches of branch-marker "MyApp" are put in
> ^/branches/MyApp (same for tags). So we effectively use the branches'
> parent dir as the "branch-marker" ... or something like that :-).
>
> Maybe "branch-context" is a better name than "branch-marker"?
>
> Thinking further about it, I think it makes some sense to establish a
> link between the branch-context, and the place where the branches
> live. For one thing, it helps to make sure that there are no name
> collisions between branches within the same branch-context. And people
> using SVN are quite used to the fact that branches/tags are part of
> the directory structure.
>
> OTOH, maybe people want to get rid of the fact that branches/tags are
> related to directories in the repository, and may want to ignore that
> a branch is located at a particular path. And if you move
> branches/tags around, you may want the branch-context to stay the same
> ... I really don't know, I haven't thought too deeply about this.
Not sure what you're saying.
I don't want to disallow people from using branch patterns such as
^/branches/2010/my-abacus-branch
^/branches/2011/my-calc-branch
^/branches/2012/my-ALU-branch
(point being the existence of intermediate dirs)
, so identifying branches by their path-wise parent would be
insufficiently generic.
And if you're talking about identifying branches by their line-of-history
parent, aka by their node origin, see Trent Nelson's post a few weeks ago.
(Though, admittedly, I re-read that post just yesterday, so I may be
somewhat biased.)
Re: Status of the 'showing-merge-info' branch
Posted by Branko Čibej <br...@xbc.nu>.
On 28.10.2011 18:21, Peter Samuelson wrote:
> [Johan Corveleyn]
>> Thinking further about it, I think it makes some sense to establish a
>> link between the branch-context, and the place where the branches
>> live. For one thing, it helps to make sure that there are no name
>> collisions between branches within the same branch-context. And
>> people using SVN are quite used to the fact that branches/tags are
>> part of the directory structure.
> That said, is it finally time to stop recommending the (IMO)
> nonsensical layout in which 'trunk' lives away from all the other
> branches? Not being too fond of extra typing, I always just put my
> branches at the same level as trunk. (This means I can't name a branch
> 'tags'. Something I've never really wanted to do anyway.) Those who
> opt for better organization at the expense of extra typing sometimes do
> the opposite, putting trunk inside the branches dir. But either way
> makes more sense than pretending trunk is not a branch.
And making branches first-class citizens makes the most sense of all.
Then once you're only allowed to merge between actual branches, about
half of all the horrible edge cases just vanish away.
(Note that one could still get the merge-arbitrary-stuff behaviour by
piping "svn diff" output through "svn patch".)
-- Brane
Re: Status of the 'showing-merge-info' branch
Posted by Peter Samuelson <pe...@p12n.org>.
[Johan Corveleyn]
> Thinking further about it, I think it makes some sense to establish a
> link between the branch-context, and the place where the branches
> live. For one thing, it helps to make sure that there are no name
> collisions between branches within the same branch-context. And
> people using SVN are quite used to the fact that branches/tags are
> part of the directory structure.
That said, is it finally time to stop recommending the (IMO)
nonsensical layout in which 'trunk' lives away from all the other
branches? Not being too fond of extra typing, I always just put my
branches at the same level as trunk. (This means I can't name a branch
'tags'. Something I've never really wanted to do anyway.) Those who
opt for better organization at the expense of extra typing sometimes do
the opposite, putting trunk inside the branches dir. But either way
makes more sense than pretending trunk is not a branch.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: Status of the 'showing-merge-info' branch
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <da...@elego.de> wrote:
> Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
>> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
>> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
>> [...]
>> >> IDENTIFYING BRANCH ROOTS
>> >>
>> >> [[[
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> >> Branch marker: 'subversion-source-tree' (found on both source and target)
>> >> [...]
>> >>
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
>> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
>> >> target has no branch marker
>> >>
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
>> >> svn: E195016: Source and target are the same branch
>> >> ]]]
>> >>
>> >> This looks for a branch root marker property on the specified
>> >> directory. The property name would be 'svn:branch-root' and the value
>> >> would be a string that (more or less uniquely) identifies the
>> >> 'project' (for want of a better word) of which this is a branch.
>> >> Currently, just for testing, the property it looks for is the first
>> >> ten characters of 'svn:ignore', which tends to work moderately well
>> >> for ad-hoc testing against our own source tree because it exists and
>> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> >> nowhere else.
>> >
>> >
>> > This feature concerns me the most. I assume we are not proposing to add
>> > this marker just for this one subcommand? I would like to see the big
>> > picture of what we would do this marker so we can discuss its format and its
>> > ramifications.
>>
>> I agree with this. A branch-roots feature can be very useful in a lot
>> of contexts, and I'd like it to be carefully designed to address some
>> shortcomings in branching/merging (and potentially tagging as well).
>>
>> For instance, it'd be nice if you could refer to the "current branch
>> root" at the command line, or in externals definitions (externals
>> relative to the branch root), or even in viewspec files
>> (svn-viewspec.py). Or if you could say:
>>
>> svn merge --reintegrate branch:showing-merge-info
>>
>> which would look for the branch-root called 'showing-merge-info', part
>> of the same 'branch-marker-space'. Or something like that (just
>> throwing ideas in the air).
>>
>> Or:
>>
>> svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
>>
>> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
>> 'namespace').
>
> Quick observation: you're asking the question "Where does the branch
> named %s live" (and I consider tags a special case of branches for the
> purposes of avoiding having to invent terminology at 2am), Julian is
> asking the question "What branch is URL %s member of?". These two
> questions don't seem directly related, my first hunch was that they're
> quite opposite.
Hm, indeed it's not the same question.Except if you structure your
branches in such a way that it is (which is the case in our
environment): all branches of branch-marker "MyApp" are put in
^/branches/MyApp (same for tags). So we effectively use the branches'
parent dir as the "branch-marker" ... or something like that :-).
Maybe "branch-context" is a better name than "branch-marker"?
Thinking further about it, I think it makes some sense to establish a
link between the branch-context, and the place where the branches
live. For one thing, it helps to make sure that there are no name
collisions between branches within the same branch-context. And people
using SVN are quite used to the fact that branches/tags are part of
the directory structure.
OTOH, maybe people want to get rid of the fact that branches/tags are
related to directories in the repository, and may want to ignore that
a branch is located at a particular path. And if you move
branches/tags around, you may want the branch-context to stay the same
... I really don't know, I haven't thought too deeply about this.
> ---
>
> Independently: can branches be nested? Say, can we have
>
> /subversion/trunk/tools/calc/trunk
>
> which gets carried along to
>
> /subversion/branches/1.7.x/tools/calc/trunk
>
> and then branches
>
> /subversion/trunk/tools/calc/branches/my-calc-branch
>
> and then someone backports that to the 1.7.x branch of calc
>
> /subversion/branches/1.7.x/tools/calc/branches/my-calc-branch
>
> and then someone asks what branch is that last thing a part of...
Yikes, that would be very confusing. I'd say (from an enterprise /
user standpoint): don't do that. If possible, this should be
disallowed, maybe blocked by one of those branch/merge-policy things
that were mentioned elsethread...
--
Johan
Re: Status of the 'showing-merge-info' branch
Posted by Daniel Shahaf <da...@elego.de>.
Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
> [...]
> >> IDENTIFYING BRANCH ROOTS
> >>
> >> [[[
> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> >> Branch marker: 'subversion-source-tree' (found on both source and target)
> >> [...]
> >>
> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
> >> target has no branch marker
> >>
> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
> >> svn: E195016: Source and target are the same branch
> >> ]]]
> >>
> >> This looks for a branch root marker property on the specified
> >> directory. The property name would be 'svn:branch-root' and the value
> >> would be a string that (more or less uniquely) identifies the
> >> 'project' (for want of a better word) of which this is a branch.
> >> Currently, just for testing, the property it looks for is the first
> >> ten characters of 'svn:ignore', which tends to work moderately well
> >> for ad-hoc testing against our own source tree because it exists and
> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
> >> nowhere else.
> >
> >
> > This feature concerns me the most. I assume we are not proposing to add
> > this marker just for this one subcommand? I would like to see the big
> > picture of what we would do this marker so we can discuss its format and its
> > ramifications.
>
> I agree with this. A branch-roots feature can be very useful in a lot
> of contexts, and I'd like it to be carefully designed to address some
> shortcomings in branching/merging (and potentially tagging as well).
>
> For instance, it'd be nice if you could refer to the "current branch
> root" at the command line, or in externals definitions (externals
> relative to the branch root), or even in viewspec files
> (svn-viewspec.py). Or if you could say:
>
> svn merge --reintegrate branch:showing-merge-info
>
> which would look for the branch-root called 'showing-merge-info', part
> of the same 'branch-marker-space'. Or something like that (just
> throwing ideas in the air).
>
> Or:
>
> svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
>
> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
> 'namespace').
Quick observation: you're asking the question "Where does the branch
named %s live" (and I consider tags a special case of branches for the
purposes of avoiding having to invent terminology at 2am), Julian is
asking the question "What branch is URL %s member of?". These two
questions don't seem directly related, my first hunch was that they're
quite opposite.
---
Independently: can branches be nested? Say, can we have
/subversion/trunk/tools/calc/trunk
which gets carried along to
/subversion/branches/1.7.x/tools/calc/trunk
and then branches
/subversion/trunk/tools/calc/branches/my-calc-branch
and then someone backports that to the 1.7.x branch of calc
/subversion/branches/1.7.x/tools/calc/branches/my-calc-branch
and then someone asks what branch is that last thing a part of...
Re: Status of the 'showing-merge-info' branch
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>
[...]
>> IDENTIFYING BRANCH ROOTS
>>
>> [[[
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> Branch marker: 'subversion-source-tree' (found on both source and target)
>> [...]
>>
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
>> svn: E195016: Source branch marker is 'subversion-source-tree' but
>> target has no branch marker
>>
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
>> svn: E195016: Source and target are the same branch
>> ]]]
>>
>> This looks for a branch root marker property on the specified
>> directory. The property name would be 'svn:branch-root' and the value
>> would be a string that (more or less uniquely) identifies the
>> 'project' (for want of a better word) of which this is a branch.
>> Currently, just for testing, the property it looks for is the first
>> ten characters of 'svn:ignore', which tends to work moderately well
>> for ad-hoc testing against our own source tree because it exists and
>> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> nowhere else.
>
>
> This feature concerns me the most. I assume we are not proposing to add
> this marker just for this one subcommand? I would like to see the big
> picture of what we would do this marker so we can discuss its format and its
> ramifications.
I agree with this. A branch-roots feature can be very useful in a lot
of contexts, and I'd like it to be carefully designed to address some
shortcomings in branching/merging (and potentially tagging as well).
For instance, it'd be nice if you could refer to the "current branch
root" at the command line, or in externals definitions (externals
relative to the branch root), or even in viewspec files
(svn-viewspec.py). Or if you could say:
svn merge --reintegrate branch:showing-merge-info
which would look for the branch-root called 'showing-merge-info', part
of the same 'branch-marker-space'. Or something like that (just
throwing ideas in the air).
Or:
svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
(where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
'namespace').
In the build-system within our company, we have introduced some
similar concepts (we keep them as hard-coded values in configuration
files as part of the build):
- We have a 'branches-root' (which refers to a subdirectory of
^/branches), which is similar to your branch-marker, or 'project'. It
configures where all the branches of this particular application or
build-variant are to be found.
- The actual branch could be called the branch-root. But we actually
call it the "codeline", for lack of a better term (I picked up this
term from some discussion on users@ a while back). Because it can
equally refer to trunk, a branch, or a tag. Some things are performed
relative to the root of the current codeline (whether the build is
based on a working copy of trunk, a branch, or a tag).
> I have a use-case for me where subtree merges are essential (and normal) so
> I do not want to see any movement away from supporting them. Eclipse
> projects very commonly have a structure like this:
> /trunk
> |- plugin1
> |- plugin2
> |- plugin3
> These plugins are all related to each other so I always branch at /trunk.
> However, in Eclipse, you do not checkout or work with trunk. You checkout
> the individual projects and these typically manifest on your disk as 3
> distinct working copies. If you are using Eclipse to merge, then you are
> doing subtree merges to each of these projects.
Ah, we have a quite similar setup actually. A single trunk with a lot
of "submodules" under it, and typically an application uses only some
of those. But they are always branched/tagged together.
That's also where "externals relative to the branch-root" would be
quite useful (so you can have an external definition pulling the
necessary submodules for your application, but only relative to the
same branch-root as the external definition itself).
> Sometimes I will use the command line or TortoiseSVN and have the entire
> tree checked out and do merges at the parent.
> Subversion handles this all quite well and I do not want to see it lost.
> Anyway, that is all just as an aside. I am not against adding the feature,
> just want to see what we plan to do with it. If you could only do a merge
> to branch-root I would have problems with that.
I'd hope that branch-roots can be equally useful for subtree merges.
At least in theory (ignoring performance implications, and complexity
in implementation). I.e. for a subtree merge, svn could still do the
same validation as in Julian's example above. It just has to find the
branch-root by walking upwards (either in the working copy, or even in
the repository if the branch-root isn't part of the checkout).
>>
>> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>>
>> [[[
>> $ svn mergeinfo
>> Assuming source branch is copied-from source of target branch. ###
>> target is implicit '.'
I had to re-read this a couple of times ("copied-from source of target
branch"). It makes sense, but it forces my mind to jump through some
hoops :-). How about "copy-source of target branch", or "parent of
target branch" (parent as in "ancestry / ancestor")?
--
Johan
Re: Status of the 'showing-merge-info' branch
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 27, 2011 at 12:05 PM, Julian Foad <ju...@wandisco.com>wrote:
> You might have posted it already but is there a "big-picture" outline
> > somewhere of where you are going with this?
>
> My goal in one sentence is to stop people accidentally messing up by
> not understanding what they're doing. The closest descriptive
> document is <http://wiki.apache.org/subversion/SimpleAndSafeMerges>.
> I believe one of the main reasons people get their mergeinfo into a
> mess (from our point of view as developers) is by running Subversion
> merges without having the correct understanding of what those commands
> are doing, and by not having a good enough view (reporting) of what
> they have done. In other words, we make it too easy for users to
> execute silly merges and not notice until it's too late. We should
> steer them towards the most common cases and display feedback that
> indicates whether they're doing something "simple and expected" or
> something "wierd" that they might not have meant.
>
OK.
> > It looks good but you are
> > saying that this is not how you intend to leave it so I am not sure what
> to
> > comment on. Improving the formatting seems like a good idea. I assume
> you
> > do not ultimately plan to mix the new formatting and the old formatting
> in
> > the same output. I assume the command line options would determine which
> > format you get.
>
> Yes, I'm thinking if you specify --show-revs={eligible|merged} you'll
> get the old simple list of revs, and if you don't specify either of
> those then you'll get the new summary instead. I'm intending the new
> output to include info about both eligible and merged revs). But
> largely this is designing 'on the fly', hence asking for any and all
> comments from time to time.
>
That is about what I expected. It will be interesting to see if you can
show both eligible and merged information at the same time in a way that is
understandable. I think if the command can show some things like there the
branch came from, or the other path that the branch is merging with, could
be useful new information. Sort of like svn info for a branch. I think it
makes sense to highly condense the revisions as they are never going to add
a lot of value in this kind of context.
> >> IDENTIFYING BRANCH ROOTS
> >>
> >> [[[
> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> >> Branch marker: 'subversion-source-tree' (found on both source and
> target)
> >> [...]
> >> ]]]
> >>
> >> This looks for a branch root marker property on the specified
> >> directory. The property name would be 'svn:branch-root' and the value
> >> would be a string that (more or less uniquely) identifies the
> >> 'project' (for want of a better word) of which this is a branch.
> >> Currently, just for testing, the property it looks for is the first
> >> ten characters of 'svn:ignore', which tends to work moderately well
> >> for ad-hoc testing against our own source tree because it exists and
> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
> >> nowhere else.
> >
> > This feature concerns me the most. I assume we are not proposing to add
> > this marker just for this one subcommand?
>
> Quite right.
>
So where I was going with this, and I am sure you are already thinking the
same way, is that if we are going to add this new property we probably need
to think of all (or as many) of the way we might use it so that we are
capturing all of the information we might need in the property. Of course,
we might decide we want separate properties.
> > I would like to see the big
> > picture of what we would do this marker so we can discuss its format and
> its
> > ramifications.
> > I have a use-case for me where subtree merges are essential (and normal)
> so
> > I do not want to see any movement away from supporting them.
>
> I do not intend to take away any functionality from those who know
> exactly what they want to do. (This is not the 'newmerge' project.)
>
That is good to know.
> OK, it's very useful to have this as en example of a good use for
> subtree merging.
>
Thanks. I think a lot of times we tend to associate the feature with
extreme cherry picking scenarios where we might be doing our users a
disservice by trying to support them. But I do believe there are a lot of
very real world scenarios that need this feature to work.
>
> >> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
> >>
> >> [[[
> >> $ svn mergeinfo
> >> Assuming source branch is copied-from source of target branch. ###
> >> target is implicit '.'
> >> [...]
> >> Source branch: ^/subversion/trunk (r1189704)
> >> Target branch: ^/subversion/branches/showing-merge-info (working copy)
> >> [...]
> >> ]]]
> >>
> >> At the moment this only looks for the copied-from branch, which is not
> >> good enough; if we do this at all then we need a way to . Stefan also
> >> suggested it should only select a source automatically when it finds a
> >> branch root marker, as that means someone has deliberately enabled the
> >> feature.
> >
> > I do not see how we can do anything other than selected the copied-from
> > unless we are going to add a feature that allows the user to specifically
> > set it somewhere, like this branch-root property. That seems like a
> problem
> > though because our normal SVN behaviors would want to propagate those
> > property changes to other copies and in merges.
>
> For now, yes; later I would like to explore the idea of the user
> providing some info somewhere about how branches are related, but I
> haven't gone anywhere with that idea yet.
>
We have the "suggest merge sources" API. That might be of some help. I
recall there was a time we considered making an "interactive merge" that
used this feature to show you the merge sources and let you choose which one
you might want.
> MAKING MERGE EXPLAIN WHAT IT'S DOING
> >>
> >> [[[
> >> $ svn merge ^/subversion/trunk
> >> Sync merge from '^/subversion/trunk' into '.' (a working copy of
> >> '^/subversion/branches/showing-merge-info')
> >> [... and maybe a summary of the revision ranges it's looking to pull in
> >> ...]
> >>
> >> $ svn merge --reintegrate ^/subversion/branches/showing-merge-info
> >> Reintegrate merge from '^/subversion/branches/showing-merge-info' into
> >> '.' (a working copy of '^/subversion/branches/trunk')
> >> The reintegrate merge will be equivalent to:
> >> merge ^/subversion/trunk@1188748
> >> ^/subversion/branches/showing-merge-info@1189710 .
> >> [...]
> >> ]]]
> >>
> >> I've only just started with this and haven't checked all of this in.
> >
> > Have to say that I do not really see the value in this one. Seems you
> could
> > just as easily argue that any of our subcommands is hard and confusing
> and
> > propose adding this sort of output to any of those commands.
> > $ svn status .
> > Checking the status of "." (a working copy of ^/trunk)
> > Seriously?
>
> No way. For a start, most commands are read-only; if you run a bunch
> of status commands on targets that don't exist or aren't in the
> working copy you thought they were or whatever, the only negative
> consequence is your momentary confusion over what you see; no state
> change occurs. On the other hand, doing a record-only merge with the
> wrong source and target (particularly if they are different paths
> relative to the branch root, like assuming src='branch1/dir/file.c'
> target='branch2/' will do the Right Thing) is a too-common and fairly
> devastating mistake.
>
> I know that printing information is not the same thing as preventing
> mistakes, but like I said at the start I'm looking for ways to make a
> "simple" merge print a simple confirming message and a "complex" one
> print something that indicates how complex it is. See for example in
> my "mergeinfo" example, I have detected whether the (recorded) merge
> was from/to the same relative path in the source as in the target, and
> either print "from same relative path" or "from source path
> 'foo/bar'". I want to make that even clearer - e.g. print nothing in
> the former case.
>
>
I am not against the idea of making the output more clear and helpful. I
know you would agree that making the output more verbose does not
automatically make it easier to understand. That was all I saw in the
examples. If there are some things we can do in the output like you suggest
then that sounds interesting and might bring some value.
It will be interesting to see you keep progressing with all of this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Status of the 'showing-merge-info' branch
Posted by Julian Foad <ju...@wandisco.com>.
Thanks for the comments, Mark. Responses in line...
Mark Phippard wrote:
> Julian Foad wrote:
>>
>> SHOWING SUMMARIZED MERGEINFO
>>
>> [[[
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> [...]
>> Revision range(s) recorded as merged:
>> to target path '.':
>> 875965,875968,...,1151036 (477 ranges) from same relative path
>> to target path 'CHANGES':
>> 875962-1130989 from same relative path
[...]
>> I want "svn mergeinfo" to show a high-level summary of the situation.
>> This currently shows the parts of the mergeinfo on the target that
>> pertain to the source branch, including subtrees, in a summarized
>> form. It could be summarized better; for instance, group together
>> several target paths that all have the same source ranges merged to
>> them.
>>
>> After that it currently goes on to print the "merged" and then the
>> "eligible" revisions as lists of individual "operative" (non-empty)
>> changes, with a (currently fake) classification of each change as a
>> "merge" or an "original commit". That's more because I'm interested in
>> the ability to do such classification, and not that I would
>> necessarily want to show that in the "mergeinfo" command output.
>
> You might have posted it already but is there a "big-picture" outline
> somewhere of where you are going with this?
My goal in one sentence is to stop people accidentally messing up by
not understanding what they're doing. The closest descriptive
document is <http://wiki.apache.org/subversion/SimpleAndSafeMerges>.
I believe one of the main reasons people get their mergeinfo into a
mess (from our point of view as developers) is by running Subversion
merges without having the correct understanding of what those commands
are doing, and by not having a good enough view (reporting) of what
they have done. In other words, we make it too easy for users to
execute silly merges and not notice until it's too late. We should
steer them towards the most common cases and display feedback that
indicates whether they're doing something "simple and expected" or
something "wierd" that they might not have meant.
> It looks good but you are
> saying that this is not how you intend to leave it so I am not sure what to
> comment on. Improving the formatting seems like a good idea. I assume you
> do not ultimately plan to mix the new formatting and the old formatting in
> the same output. I assume the command line options would determine which
> format you get.
Yes, I'm thinking if you specify --show-revs={eligible|merged} you'll
get the old simple list of revs, and if you don't specify either of
those then you'll get the new summary instead. I'm intending the new
output to include info about both eligible and merged revs). But
largely this is designing 'on the fly', hence asking for any and all
comments from time to time.
>> IDENTIFYING BRANCH ROOTS
>>
>> [[[
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> Branch marker: 'subversion-source-tree' (found on both source and target)
>> [...]
>> ]]]
>>
>> This looks for a branch root marker property on the specified
>> directory. The property name would be 'svn:branch-root' and the value
>> would be a string that (more or less uniquely) identifies the
>> 'project' (for want of a better word) of which this is a branch.
>> Currently, just for testing, the property it looks for is the first
>> ten characters of 'svn:ignore', which tends to work moderately well
>> for ad-hoc testing against our own source tree because it exists and
>> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> nowhere else.
>
> This feature concerns me the most. I assume we are not proposing to add
> this marker just for this one subcommand?
Quite right.
> I would like to see the big
> picture of what we would do this marker so we can discuss its format and its
> ramifications.
> I have a use-case for me where subtree merges are essential (and normal) so
> I do not want to see any movement away from supporting them.
I do not intend to take away any functionality from those who know
exactly what they want to do. (This is not the 'newmerge' project.)
> Eclipse
> projects very commonly have a structure like this:
> /trunk
> |- plugin1
> |- plugin2
> |- plugin3
> These plugins are all related to each other so I always branch at /trunk.
> However, in Eclipse, you do not checkout or work with trunk. You checkout
> the individual projects and these typically manifest on your disk as 3
> distinct working copies. If you are using Eclipse to merge, then you are
> doing subtree merges to each of these projects.
> Sometimes I will use the command line or TortoiseSVN and have the entire
> tree checked out and do merges at the parent.
> Subversion handles this all quite well and I do not want to see it lost.
OK, it's very useful to have this as en example of a good use for
subtree merging.
> Anyway, that is all just as an aside. I am not against adding the feature,
> just want to see what we plan to do with it. If you could only do a merge
> to branch-root I would have problems with that.
>> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>>
>> [[[
>> $ svn mergeinfo
>> Assuming source branch is copied-from source of target branch. ###
>> target is implicit '.'
>> [...]
>> Source branch: ^/subversion/trunk (r1189704)
>> Target branch: ^/subversion/branches/showing-merge-info (working copy)
>> [...]
>> ]]]
>>
>> At the moment this only looks for the copied-from branch, which is not
>> good enough; if we do this at all then we need a way to . Stefan also
>> suggested it should only select a source automatically when it finds a
>> branch root marker, as that means someone has deliberately enabled the
>> feature.
>
> I do not see how we can do anything other than selected the copied-from
> unless we are going to add a feature that allows the user to specifically
> set it somewhere, like this branch-root property. That seems like a problem
> though because our normal SVN behaviors would want to propagate those
> property changes to other copies and in merges.
For now, yes; later I would like to explore the idea of the user
providing some info somewhere about how branches are related, but I
haven't gone anywhere with that idea yet.
> MAKING MERGE EXPLAIN WHAT IT'S DOING
>>
>> [[[
>> $ svn merge ^/subversion/trunk
>> Sync merge from '^/subversion/trunk' into '.' (a working copy of
>> '^/subversion/branches/showing-merge-info')
>> [... and maybe a summary of the revision ranges it's looking to pull in
>> ...]
>>
>> $ svn merge --reintegrate ^/subversion/branches/showing-merge-info
>> Reintegrate merge from '^/subversion/branches/showing-merge-info' into
>> '.' (a working copy of '^/subversion/branches/trunk')
>> The reintegrate merge will be equivalent to:
>> merge ^/subversion/trunk@1188748
>> ^/subversion/branches/showing-merge-info@1189710 .
>> [...]
>> ]]]
>>
>> I've only just started with this and haven't checked all of this in.
>
> Have to say that I do not really see the value in this one. Seems you could
> just as easily argue that any of our subcommands is hard and confusing and
> propose adding this sort of output to any of those commands.
> $ svn status .
> Checking the status of "." (a working copy of ^/trunk)
> Seriously?
No way. For a start, most commands are read-only; if you run a bunch
of status commands on targets that don't exist or aren't in the
working copy you thought they were or whatever, the only negative
consequence is your momentary confusion over what you see; no state
change occurs. On the other hand, doing a record-only merge with the
wrong source and target (particularly if they are different paths
relative to the branch root, like assuming src='branch1/dir/file.c'
target='branch2/' will do the Right Thing) is a too-common and fairly
devastating mistake.
I know that printing information is not the same thing as preventing
mistakes, but like I said at the start I'm looking for ways to make a
"simple" merge print a simple confirming message and a "complex" one
print something that indicates how complex it is. See for example in
my "mergeinfo" example, I have detected whether the (recorded) merge
was from/to the same relative path in the source as in the target, and
either print "from same relative path" or "from source path
'foo/bar'". I want to make that even clearer - e.g. print nothing in
the former case.
- Julian
Re: Status of the 'showing-merge-info' branch
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com>wrote:
> At the moment, on the 'showing-merge-info' branch, I have several
> things going on; here are some of them.
>
>
> SHOWING SUMMARIZED MERGEINFO
>
> [[[
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> [...]
> Revision range(s) recorded as merged:
> to target path '.':
> 875965,875968,...,1151036 (477 ranges) from same relative path
> to target path 'CHANGES':
> 875962-1130989 from same relative path
> to target path 'get-deps.sh':
> 878590,878607,...,1126007 (7 ranges) from same relative path
> to target path 'subversion/include/private/svn_repos_private.h':
> 878590,878607,...,1126007 (17 ranges) from same relative path
> to target path 'subversion/libsvn_fs_fs/rep-cache.c':
> 875965,875968,...,1126007 (456 ranges) from same relative path
> to target path 'subversion/tests/cmdline/merge_tests.py':
> 875965,875968,...,1126007 (432 ranges) from same relative path
> 953878,1146121 from source path
> 'subversion/tests/cmdline/merge_reintegrate_tests.py'
> to target path 'subversion/tests/cmdline/svntest/main.py':
> 991972 from source path
> 'subversion/tests/cmdline/svntest/sandbox.py'
> 875965,875968,...,1126007 (441 ranges) from same relative path
> ]]]
>
> I want "svn mergeinfo" to show a high-level summary of the situation.
> This currently shows the parts of the mergeinfo on the target that
> pertain to the source branch, including subtrees, in a summarized
> form. It could be summarized better; for instance, group together
> several target paths that all have the same source ranges merged to
> them.
>
> After that it currently goes on to print the "merged" and then the
> "eligible" revisions as lists of individual "operative" (non-empty)
> changes, with a (currently fake) classification of each change as a
> "merge" or an "original commit". That's more because I'm interested in
> the ability to do such classification, and not that I would
> necessarily want to show that in the "mergeinfo" command output.
>
You might have posted it already but is there a "big-picture" outline
somewhere of where you are going with this? It looks good but you are
saying that this is not how you intend to leave it so I am not sure what to
comment on. Improving the formatting seems like a good idea. I assume you
do not ultimately plan to mix the new formatting and the old formatting in
the same output. I assume the command line options would determine which
format you get.
IDENTIFYING BRANCH ROOTS
>
> [[[
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> Branch marker: 'subversion-source-tree' (found on both source and target)
> [...]
>
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
> svn: E195016: Source branch marker is 'subversion-source-tree' but
> target has no branch marker
>
> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
> svn: E195016: Source and target are the same branch
> ]]]
>
> This looks for a branch root marker property on the specified
> directory. The property name would be 'svn:branch-root' and the value
> would be a string that (more or less uniquely) identifies the
> 'project' (for want of a better word) of which this is a branch.
> Currently, just for testing, the property it looks for is the first
> ten characters of 'svn:ignore', which tends to work moderately well
> for ad-hoc testing against our own source tree because it exists and
> starts with 'ChangeLog*' in the root of every branch and (I guess)
> nowhere else.
>
This feature concerns me the most. I assume we are not proposing to add
this marker just for this one subcommand? I would like to see the big
picture of what we would do this marker so we can discuss its format and its
ramifications.
I have a use-case for me where subtree merges are essential (and normal) so
I do not want to see any movement away from supporting them. Eclipse
projects very commonly have a structure like this:
/trunk
|- plugin1
|- plugin2
|- plugin3
These plugins are all related to each other so I always branch at /trunk.
However, in Eclipse, you do not checkout or work with trunk. You checkout
the individual projects and these typically manifest on your disk as 3
distinct working copies. If you are using Eclipse to merge, then you are
doing subtree merges to each of these projects.
Sometimes I will use the command line or TortoiseSVN and have the entire
tree checked out and do merges at the parent.
Subversion handles this all quite well and I do not want to see it lost.
Anyway, that is all just as an aside. I am not against adding the feature,
just want to see what we plan to do with it. If you could only do a merge
to branch-root I would have problems with that.
IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>
> [[[
> $ svn mergeinfo
> Assuming source branch is copied-from source of target branch. ###
> target is implicit '.'
> [...]
> Source branch: ^/subversion/trunk (r1189704)
> Target branch: ^/subversion/branches/showing-merge-info (working copy)
> [...]
> ]]]
>
> At the moment this only looks for the copied-from branch, which is not
> good enough; if we do this at all then we need a way to . Stefan also
> suggested it should only select a source automatically when it finds a
> branch root marker, as that means someone has deliberately enabled the
> feature.
>
I do not see how we can do anything other than selected the copied-from
unless we are going to add a feature that allows the user to specifically
set it somewhere, like this branch-root property. That seems like a problem
though because our normal SVN behaviors would want to propagate those
property changes to other copies and in merges.
MAKING MERGE EXPLAIN WHAT IT'S DOING
>
> [[[
> $ svn merge ^/subversion/trunk
> Sync merge from '^/subversion/trunk' into '.' (a working copy of
> '^/subversion/branches/showing-merge-info')
> [... and maybe a summary of the revision ranges it's looking to pull in
> ...]
>
> $ svn merge --reintegrate ^/subversion/branches/showing-merge-info
> Reintegrate merge from '^/subversion/branches/showing-merge-info' into
> '.' (a working copy of '^/subversion/branches/trunk')
> The reintegrate merge will be equivalent to:
> merge ^/subversion/trunk@1188748
> ^/subversion/branches/showing-merge-info@1189710 .
> [...]
> ]]]
>
> I've only just started with this and haven't checked all of this in.
>
Have to say that I do not really see the value in this one. Seems you could
just as easily argue that any of our subcommands is hard and confusing and
propose adding this sort of output to any of those commands.
$ svn status .
Checking the status of "." (a working copy of ^/trunk)
Seriously?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Status of the 'showing-merge-info' branch
Posted by Julian Foad <ju...@wandisco.com>.
Thanks for the comments, Paul. Responses in line...
Paul Burba wrote:
> Julian Foad wrote:
>> I want "svn mergeinfo" to show a high-level summary of the situation.
>
> Will we still be able to produce the old-style output via an option?
Yes, certainly; that code is currently absent from the branch for
simplicity but yes; that was discussed previously
<http://svn.haxx.se/dev/archive-2011-10/0048.shtml>.
>> This currently shows the parts of the mergeinfo on the target that
>> pertain to the source branch, including subtrees, in a summarized
>> form. It could be summarized better; for instance, group together
>> several target paths that all have the same source ranges merged to
>> them.
>
> While we are in this space it's probably worth doing something about
> mixed-rev working copies. Right now the 'svn mergeinfo' subcommand on
> both trunk and your branch doesn't account for (heck, it doesn't even
> *notice*) mixed-rev targets.[...]
OK, thanks, I'll think about that.
>> After that it currently goes on to print the "merged" and then the
>> "eligible" revisions as lists of individual "operative" (non-empty)
>> changes, with a (currently fake) classification of each change as a
>> "merge" or an "original commit". That's more because I'm interested in
>> the ability to do such classification, and not that I would
>> necessarily want to show that in the "mergeinfo" command output.
>
> smi>svn info
> Path: .
> Working Copy Root Path: C:\SVN\src-trunk-2
> URL: https://svn.apache.org/repos/asf/subversion/branches/showing-merge-info
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1189744
> Node Kind: directory
> Schedule: normal
> Last Changed Author: julianfoad
> Last Changed Rev: 1189146
> Last Changed Date: 2011-10-26 07:56:31 -0400 (Wed, 26 Oct 2011)
>
> smi>svn mergeinfo
> Assuming source branch is copied-from source of target branch.
> Branch marker: 'ChangeLog*' (found on both source and target)
> Source branch: ^/subversion/trunk (r1189762)
> Target branch: ^/subversion/branches/showing-merge-info (working copy)
>
> ### It might be helpful to show the revision of the working copy target too.
Yes; I initially didprint the directory's rev, but then, because
that's misleading for mixed-rev, I pulled it out. Probably best to
run the "svnversion" code to find out whether it's mixed-rev, and
print accordingly.
> Revision range that could be merged:
> origin-1189762
>
> ### So this line just shows "origin-Source_HEAD_Rev"? That's a bit misleading
> ### since origin-1188748 *has* been merged already. Might be more useful
> ### if 'origin' were replaced with the youngest revision from the source that
> ### the target has been fully synced to (+1 of course since you are using the
> ### 'M-N' range notation rather than 'M:N'):
> ###
> ### Revision range that could be merged:
> ### 1188749-1189762
That info is going to come out in the "what's been merged" section.
What I intend here is ...
> ### Or maybe just spell out the actual value of the copied-from source + 1:
> ###
> ### Revision range that could be merged:
> ### 1177607-1189762
... yes, that. It's only missing at the moment because the API I'm
calling doesn't provide it.
> Revision range(s) recorded as merged:
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 753:
> /subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.c[1]:
> 1067687-1072301
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 753:
> /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c[1]:
> 1067687-1072301
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[59], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 753: /subversion/trunk[1]: 1177607-1188748
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 753:
> /subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.h[1]:
> 1067687-1072301
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[46], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[4], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
> subversion/trunk)
> DBG: mergeinfo.c: 753:
> /subversion/trunk/subversion/include/private/svn_temp_serializer.h[1]:
> 1067687-1072301
> to target path '.':
> 1177607-1188748 from same relative path
> to target path 'subversion/include/private/svn_temp_serializer.h':
> 1067687-1072301 from same relative path
> to target path 'subversion/libsvn_fs_fs/temp_serializer.c':
> 1067687-1072301 from same relative path
> to target path 'subversion/libsvn_fs_fs/temp_serializer.h':
> 1067687-1072301 from same relative path
> to target path 'subversion/libsvn_subr/svn_temp_serializer.c':
> 1067687-1072301 from same relative path
>
> Merged revisions:
> r1067687 -- merge *
> r1067696 -- merge *
> r1067712 -- merge *
> r1067714 -- change (at least on some paths) *
>
> ### I know this is work in progress, so maybe you are already aware of this
> ### but all of these revisions predate the rev in which
> ### ^/subversion/branches/showing-merge-info was branched from
> ### ^/subversion/trunk, i.e. 1177607, so they are neither merged nor
> ### eligible, rather they are part of the common history of the two.
Yes; I *think* that's because of the strange mergeinfo on all the
temp_serializer files, which I should be filtering it out because it's
outside the relevant range, but I haven't implemented that part of the
filter yet in "svn_client__get_source_target_mergeinfo()". (That's a
poor function name as Stefan or Daniel already pointed out on IRC.)
> ...
> Eligible revisions:
> r1177693 -- change (at least on some paths) *
> r1177700 -- no-op *
> r1177702 -- change (at least on some paths) *
> r1177732 -- change (at least on some paths) *
>
> ### These revs are not correct either. This branch is synced with
> trunk through
> ### r1188748, so all of these revisions *have* been merged. Also, r1177700
> ### is flagged as a no-op, but like the other three changes was operative and
> ### was merged to the branch in r1182334.
Yup. The "no-op" and "change" flags are fake: the flagging code
currently just says "no-op" when (REV % 10 == 0). That's why I didn't
mention this stuff in the email. It would certainly be helpful if I
made it print a warning about this, now that you and potentially
others are looking at this branch and running it. Sorry to spring
that on you!
>> IDENTIFYING BRANCH ROOTS
[...]
> The section on subtrees in
> http://wiki.apache.org/subversion/SupportedMergeScenarios is blank. I
> assume you still plan to support merge-tracking aware subtree merges
> right? The concept of a branch root is only to encourage best
> practices and enable new features (i.e. the identification of source
> branches below).
Yes, correct.
>> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>>
>> [[[
>> $ svn mergeinfo
>> Assuming source branch is copied-from source of target branch. ###
>> target is implicit '.'
>> [...]
>> Source branch: ^/subversion/trunk (r1189704)
>> Target branch: ^/subversion/branches/showing-merge-info (working copy)
>> [...]
>> ]]]
>>
>> At the moment this only looks for the copied-from branch, which is not
>> good enough; if we do this at all then we need a way to . Stefan also
>
> A way to what? Looks like you stopped mid-though here. I know the
> feeling when it comes to merge :-)
Oops. A way to be able to support less "obvious" branching patterns,
e.g. copy trunk to br-1.0, copy trunk to br-1.1, then decide to use
br-1.1 as if it's a sub-branch of br-1.0. And so on. People do that
sort of thing.
>> suggested it should only select a source automatically when it finds a
>> branch root marker, as that means someone has deliberately enabled the
>> feature.
- Julian
Re: Status of the 'showing-merge-info' branch
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <ju...@wandisco.com> wrote:
> At the moment, on the 'showing-merge-info' branch, I have several
> things going on; here are some of them.
>
> SHOWING SUMMARIZED MERGEINFO
>
> [[[
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> [...]
> Revision range(s) recorded as merged:
> to target path '.':
> 875965,875968,...,1151036 (477 ranges) from same relative path
> to target path 'CHANGES':
> 875962-1130989 from same relative path
> to target path 'get-deps.sh':
> 878590,878607,...,1126007 (7 ranges) from same relative path
> to target path 'subversion/include/private/svn_repos_private.h':
> 878590,878607,...,1126007 (17 ranges) from same relative path
> to target path 'subversion/libsvn_fs_fs/rep-cache.c':
> 875965,875968,...,1126007 (456 ranges) from same relative path
> to target path 'subversion/tests/cmdline/merge_tests.py':
> 875965,875968,...,1126007 (432 ranges) from same relative path
> 953878,1146121 from source path
> 'subversion/tests/cmdline/merge_reintegrate_tests.py'
> to target path 'subversion/tests/cmdline/svntest/main.py':
> 991972 from source path
> 'subversion/tests/cmdline/svntest/sandbox.py'
> 875965,875968,...,1126007 (441 ranges) from same relative path
> ]]]
Hi Julian,
Questions and comments below. All examples done with
^/subversion/branches/showing-merge-info@1189744.
> I want "svn mergeinfo" to show a high-level summary of the situation.
Will we still be able to produce the old-style output via an option?
> This currently shows the parts of the mergeinfo on the target that
> pertain to the source branch, including subtrees, in a summarized
> form. It could be summarized better; for instance, group together
> several target paths that all have the same source ranges merged to
> them.
While we are in this space it's probably worth doing something about
mixed-rev working copies. Right now the 'svn mergeinfo' subcommand on
both trunk and your branch doesn't account for (heck, it doesn't even
*notice*) mixed-rev targets. At a minimum 'svn mergeinfo' should
issue some sort of warning akin to what an actual merge generates,
e.g.:
smi>svn merge ^^/subversion/trunk
svn: E195020: Cannot merge into mixed-revision working copy
[1179544:1189744]; try updating first
A few options we might pursue:
1) Refuse outright to operate on a mixed-rev target, raise an error,
and recommend updating to a uniform revisions
2) Proceed, but warn that the target is mixed-rev and the results of
an actual merge may not be what is expected (i.e. conflicts).
3) Other?
> After that it currently goes on to print the "merged" and then the
> "eligible" revisions as lists of individual "operative" (non-empty)
> changes, with a (currently fake) classification of each change as a
> "merge" or an "original commit". That's more because I'm interested in
> the ability to do such classification, and not that I would
> necessarily want to show that in the "mergeinfo" command output.
smi>svn info
Path: .
Working Copy Root Path: C:\SVN\src-trunk-2
URL: https://svn.apache.org/repos/asf/subversion/branches/showing-merge-info
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1189744
Node Kind: directory
Schedule: normal
Last Changed Author: julianfoad
Last Changed Rev: 1189146
Last Changed Date: 2011-10-26 07:56:31 -0400 (Wed, 26 Oct 2011)
smi>svn mergeinfo
Assuming source branch is copied-from source of target branch.
Branch marker: 'ChangeLog*' (found on both source and target)
Source branch: ^/subversion/trunk (r1189762)
Target branch: ^/subversion/branches/showing-merge-info (working copy)
### It might be helpful to show the revision of the working copy target too.
Revision range that could be merged:
origin-1189762
### So this line just shows "origin-Source_HEAD_Rev"? That's a bit misleading
### since origin-1188748 *has* been merged already. Might be more useful
### if 'origin' were replaced with the youngest revision from the source that
### the target has been fully synced to (+1 of course since you are using the
### 'M-N' range notation rather than 'M:N'):
###
### Revision range that could be merged:
### 1188749-1189762
###
### Or maybe just spell out the actual value of the copied-from source + 1:
###
### Revision range that could be merged:
### 1177607-1189762
###
Revision range(s) recorded as merged:
DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.c[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[59], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753: /subversion/trunk[1]: 1177607-1188748
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.h[1]:
1067687-1072301
DBG: mergeinfo.c: 738: filter_mergeinfo(in[46], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[4], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762
subversion/trunk)
DBG: mergeinfo.c: 753:
/subversion/trunk/subversion/include/private/svn_temp_serializer.h[1]:
1067687-1072301
to target path '.':
1177607-1188748 from same relative path
to target path 'subversion/include/private/svn_temp_serializer.h':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_fs_fs/temp_serializer.c':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_fs_fs/temp_serializer.h':
1067687-1072301 from same relative path
to target path 'subversion/libsvn_subr/svn_temp_serializer.c':
1067687-1072301 from same relative path
Merged revisions:
r1067687 -- merge *
r1067696 -- merge *
r1067712 -- merge *
r1067714 -- change (at least on some paths) *
### I know this is work in progress, so maybe you are already aware of this
### but all of these revisions predate the rev in which
### ^/subversion/branches/showing-merge-info was branched from
### ^/subversion/trunk, i.e. 1177607, so they are neither merged nor
### eligible, rather they are part of the common history of the two.
...
Eligible revisions:
r1177693 -- change (at least on some paths) *
r1177700 -- no-op *
r1177702 -- change (at least on some paths) *
r1177732 -- change (at least on some paths) *
### These revs are not correct either. This branch is synced with
trunk through
### r1188748, so all of these revisions *have* been merged. Also, r1177700
### is flagged as a no-op, but like the other three changes was operative and
### was merged to the branch in r1182334.
...
smi>
> IDENTIFYING BRANCH ROOTS
>
> [[[
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
> Branch marker: 'subversion-source-tree' (found on both source and target)
> [...]
>
> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
> svn: E195016: Source branch marker is 'subversion-source-tree' but
> target has no branch marker
>
> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
> svn: E195016: Source and target are the same branch
> ]]]
>
> This looks for a branch root marker property on the specified
> directory. The property name would be 'svn:branch-root' and the value
> would be a string that (more or less uniquely) identifies the
> 'project' (for want of a better word) of which this is a branch.
> Currently, just for testing, the property it looks for is the first
> ten characters of 'svn:ignore', which tends to work moderately well
> for ad-hoc testing against our own source tree because it exists and
> starts with 'ChangeLog*' in the root of every branch and (I guess)
> nowhere else.
The section on subtrees in
http://wiki.apache.org/subversion/SupportedMergeScenarios is blank. I
assume you still plan to support merge-tracking aware subtree merges
right? The concept of a branch root is only to encourage best
practices and enable new features (i.e. the identification of source
branches below).
>
> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>
> [[[
> $ svn mergeinfo
> Assuming source branch is copied-from source of target branch. ###
> target is implicit '.'
> [...]
> Source branch: ^/subversion/trunk (r1189704)
> Target branch: ^/subversion/branches/showing-merge-info (working copy)
> [...]
> ]]]
>
> At the moment this only looks for the copied-from branch, which is not
> good enough; if we do this at all then we need a way to . Stefan also
A way to what? Looks like you stopped mid-though here. I know the
feeling when it comes to merge :-)
> suggested it should only select a source automatically when it finds a
> branch root marker, as that means someone has deliberately enabled the
> feature.
>
>
> MAKING MERGE EXPLAIN WHAT IT'S DOING
>
> [[[
> $ svn merge ^/subversion/trunk
> Sync merge from '^/subversion/trunk' into '.' (a working copy of
> '^/subversion/branches/showing-merge-info')
> [... and maybe a summary of the revision ranges it's looking to pull in ...]
>
> $ svn merge --reintegrate ^/subversion/branches/showing-merge-info
> Reintegrate merge from '^/subversion/branches/showing-merge-info' into
> '.' (a working copy of '^/subversion/branches/trunk')
> The reintegrate merge will be equivalent to:
> merge ^/subversion/trunk@1188748
> ^/subversion/branches/showing-merge-info@1189710 .
> [...]
> ]]]
>
> I've only just started with this and haven't checked all of this in.
>
> We say that 'reintegrate' does a two-URL merge, but in wanting to make
> it print what it's about to do I notice that the implementation
> doesn't seem to call the two-URL merge code at all. I want to change
> that and have the two phases completely separated: first the client
> should figure out what merge it will do, and print that, then call the
> two-URL merge code to actually do it.
>
>
> Comments appreciated.
>
> - Julian
>