On Fri, Oct 28, 2011 at 10:21 AM, Daniel Shahaf <danie...@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 <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.
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
