On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.foad_at_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
Received on 2011-10-27 22:25:11 CEST