Johan Corveleyn wrote on Fri, Oct 28, 2011 at 10:53:43 +0200:
> On Fri, Oct 28, 2011 at 10:21 AM, Daniel Shahaf <danielsh_at_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 <danielsh_at_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 <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').
> >> >
> >> > 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)
Received on 2011-10-28 11:12:55 CEST