Karl Fogel wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>
>> What's the new recommendation for all those folks that been sharding their
>> branches directory by branch types for all these years (into things like
>> branches/dev, branches/release, branches/feature)? Do they use
>> branches/release/current? branches/feature/those-too-small-for-branches?
>> Why not throw tags in there, too, as branches/please-dont-change-these? But
>> then, if all the branches and tags are in there together, why not just move
>> them to the root of the project and shard them by their conceptual meanings
>> -- you know, like /trunk, /tags, and /branches?
>>
>> I believe there's value in being able to easily identify the conceptual
>> trunk of a project's development. I believe that the easiest way to do so
>> is using the TTB structure we've been advocating for a decade. And I
>> believe that no one with any measure of clue is suffering today as a result
>> of that recommendation.
>>
>> -1.
>>
>
> On more careful thought, Mike's and Greg's arguments are more convincing
> to me. While there are some slight advantages to having it be
> symmetrical with other branches, there are 10 years of TTB convention
> behind the current method, and it hasn't really gotten in anyone's way
> that I've ever seen. A little bit of special case code here and there,
> but then again one is usually special-casing trunk anyway.
>
> And as Mike points out, we've never recommended that all branches be at
> the top level of "branches" anyway; many people put some in
> sub-sub-directories.
Could someone please explain to me how that is easier to keep track of?
I've seen a repository like that .... it was a total, horrible mess of
cross--level dependencies and spaghetti externals that no amount of
documentation was able to untangle. The projects that lived in it died a
horrible death.
> Er, including us:
>
> $ svn ls http://svn.collab.net/repos/svn/branches/meta-data-versioning/
>
> *cough* *cough* :-)
>
> -0.5 on this change, unless we can come up with stronger practical
> arguments.
>
Ok, so symmetry aside ... If you look at almost any reasonable text on
configuration management, it talks about trees and similar hierarchies
of branches. But because, unlike some other version control systems,
Subversion does not easily lend itself to structuring the /naming/ of
branches hierarchically (except through tricks like dashes or dots in
the branch name), I'm not proposing that; I'm proposing the exact
opposite, that we /simplify/ our branching schema, not complicate it, by
putting all branches in the same bag. We only keep the tags and branches
namespaces separate because that's a useful separation.
(I'm somewhat surprised by CMike's apparent accusation that I'm
proposing something /more/ complicated than what we have, maybe I
misread it.)
Anyway, I've seen any number of times, in real life (and had to deal
with it, sigh), that making trunk special in terms of naming causes
problems. Unfortunately I can't bring those examples and show them here;
inhuman restrictions, don't y'know. But I could dig in archives, too, I
seem to recall some examples of that from a few years ago.
(And by the way, conceding for the sake of argument that /trunk is
special, I can't see why it would be less special just because it was
called /branches/trunk)
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417266
Received on 2009-11-12 22:39:40 CET