> > 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>>
