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
Received on 2013-05-16 09:34:20 CEST