> > So what's the actual problem (or problems) with SVN's branching and
> > tagging? Where does it hurt your workflow? What would make SVN not
> > "hurt you" in that way?
> >
> > Please be concrete, and give examples of what really bothers you as a
> > user or an admin in your daily work. Saying that "branches are not
> > first class", or "I don't like it that Subversion implements
> > branches/tags by copying directories" are too abstract, and really not
> > relevant. Why should I care how SVN implements its branches
> > internally, as long as it works for the use cases I need?
> >
> > The only concrete problem I've read so far (I don't remember if it was
> > in this thread or another one) is that copying the parent of all
> > branches (or tags) shows up as a revision when you "svn log" the
> > branch. So okay, that's one thing. Any others?
> >
>
> Correct, changing the parent dir of a branch injects a "spurious" log entry in
> your branches (or tags) sub dirs, which is morally wrong because branches (and
> tags) should be isolated from outside changes. I documented this in the
> original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you
> "svn copy ^/porject1 ^/project" to fix the naming problem then everything
> under branches and tags gets the spurious revision. The spurious revision also
> triggers on --stop-on-copy which needlessly complicates ancestry tracking.
>
> However, given how svn works, I'm not sure that it is technically a technical
> issue. =) Instead, is it a "branches as first class objects" requirement?
What do you mean by "spurious" log entries? When I look at the log (at least in the tsvn log viewer) I only see revisions that have changes on that path. I don't see every revision number unless I go to the project root path or repository root path.
<<snip>>
Received on 2013-05-21 19:24:30 CEST