"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. 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.
-Karl
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417254
Received on 2009-11-12 22:18:17 CET