On 15.05.2013 19:06, Andrew Reedick wrote: > Isolating change is a fundamental tenet behind branching. The fact that an > "outside" change can affect a branch (and a tagged baseline) is wrong by > definition.
I suspect this discussion has strayed somewhat from the mandate of this list ... so let me try to wrap it up. The kind of branch semantics that you propose can be achieved in Subversion by using the top-level directory of a repository as the root of all branches. Subversion could "easily" do this in some future (backward-incompatible) version by, e.g., simply hiding that root level and calling it the branch namespace. However, that would not in any way simplify the task of tracking file-level cherry-picks or partial merges (both of which, I'll take the liberty to point out, git tends to ignore). I agree it would be nice if Subversion had first-class branches from day one, and settled for a far simpler object model; at least we wouldn't be in the situation where it's possible to have two branches of the same file in the same directory (which makes the merge tracking problem an order of magnitude harder). On the other hand, it would hardly be a service to our users if we drastically broke backwards compatibility by fundamentally changing the object model; regardless of anyone's opinion about the decisions that lead to it being the way it is. Instead, we're working within the constraints of that model with the goal to address many -- but obviously not all -- of the concerns raised in this thread. And a final note: Subversion is not intended to be the ideal tool for every situation, and never will be. If Subversion's features cannot support your workflow, there are only two solutions: change the workflow, or replace Subversion. Both are valid decisions, and neither is trivial. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com