Johan Corveleyn wrote on Fri, Oct 28, 2011 at 09:38:57 +0200:
> On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <danie...@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 <markp...@gmail.com> wrote:
> >> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.f...@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.)
