On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.foad_at_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_at_1188748
> ^/subversion/branches/showing-merge-info_at_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/
Received on 2011-10-27 15:58:24 CEST