On Feb 19, 2008 2:23 PM, Michael Haggerty <mhagger_at_alum.mit.edu> wrote:
> Branko Čibej wrote:
> > Michael Haggerty wrote:
> >> I've thought that it would make sense to add a property to the trunk
> >> directory that indicates "this is a project root directory" (in the
> >> sense that it is the root of a source code tree, typically the level
> >> that users check out). [...]
> > Reading this and similar proposals makes me want to cry. People keep
> > proposing hacks upon hacks upon hacks instead of recognizing the
> > fundamental truth that our branching model is broken.
> Brane, you already persuaded me at the SVN summit that Subversion's
> current branching model should be buried as an implementation detail.
> In fact, the branching model that I use in cvs2svn separates the line of
> development namespace from the file namespace just as you advocate
> because (1) it is simpler to implement; (2) it is a better match to CVS
> branches and tags; and (3) it is a better match to git's model, which is
> the other output SCM that we currently support. But given that the
> Subversion world isn't changing soon, a simple hack like this (almost
> zero work) might ease the pain a little bit. And in the unlikely case
> that SVN ever changes its branching model, something like the suggested
> property could help with forwards and backwards compatibility.
> David Glasser wrote:
> > Of course, finding such properties, noticing updates to them, etc, is
> > not actually trivial under the svn model (see the incredible amount of
> > effort required to make mergeinfo inheritance work, and it still has
> > some holes).
> True, but there are far fewer project lines of development than merges,
> and only one level of any SVN path in a conventionally-structured SVN
> repository should ever have this property. The most common questions
> would be: what line of development does this file belong to? (traverse
> path towards root until a project root directory is found) and what is
> the complete list of lines of development in this repository?
> (breadth-first tree walk starting at root and pruning whenever a project
> root is found).
I agree; in fact this matches my personal favorite model for a "sane"
svn copy/branch semantics. Just pointing out that, given svn's
client/server model, knowing the answer to those two "common
questions" in the client isn't always so easy. (Brane aptly points
out that this is a flaw in our choice of client vs server
David Glasser | firstname.lastname@example.org | http://www.davidglasser.net/
Received on 2008-02-19 23:28:19 CET