On Dec 1, 2007 5:41 AM, Branko Èibej <brane@xbc.nu> wrote:
> Ben Collins-Sussman wrote:
> > On Nov 30, 2007 6:15 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> >
> >>> Yes, this is what the plan has been for quite a while now.
> >>>
> >> I'm glad to hear you say this :-). But, others seem to think
> >> differently, so it's important we hear from them too...
> >>
> >
> > I'm not sure what to say, guys. So much drama in such a small period
> > of time. Eesh.
> >
> > I know it's ridiculous (and rude) for a bunch of people who haven't
> > been paying attention to merge-tracking details show up at the last
> > minute and challenge a bunch of decisions that were made months ago...
> >
>
> ... but I'm going to be even ruder and more ridiculous anyway. Guys ...
> deferring basic functionality that everyone else (except CVS and
> SourceSafe) takes for granted -- after almost two years spent working
> heavily on merge tracking -- is a bit of a bore. Even more so because
> there's already an efficient way of doing merges right with a Subversion
> repository: it's called git-svn and works like a charm. Oh, and of
> course there's svk.
>
> Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
> summit, Subversion is treading water. In the last two years, have we
> added *any* feature that's more useful than the code bloat it produced?
> We've not even solved the relatively simple problem of working correctly
> on case-insensitive filesystems -- which just happens to include about
> 99% of all computers in the world, according to latest estimates. Many
> version control projects that didn't even exist when svn-1.0 came out
> have caught up and surpassed Subversion in terms of version control
> functionality, performance and (!) reliability, while we've wasted time
> with non-profit corporations and trademark protection.
>
> I'm not going to try to analyze the reasons here, except to note that
> losing sight of the ball does not help, nor does resting on laurels.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
>
> So ... we've made many wrong decisions, and I admit to making or
> supporting quite a few of them. But I don't see any reason for
> perpetuating them. So I suggest you (we?) all take a step back and
> *seriously* start moving in the right direction; otherwise in the next
> few years, Subversion and CVS will be jostling for the best position in
> the dinosaur exhibit of the trash-heap of history.
I agree with Brane in part. After all, it's pretty easy to look at a
distributed system like hg or git and say "merge tracking is so easy
there, it barely even qualifies as a feature! why is svn so dumb?"
And in fact, if the model of hg (I'll use hg as an example because
it's the distributed system I know best) was strictly better than
Subversion's model in all ways, then continuing with the Subversion
model would clearly be silly.
So what are the differences between the Subversion and the hg model
that makes merging so easy for them and so hard for us?
The obvious answer is "they have deep history in the client; we
don't". However, I *don't* actually think that this is what makes our
merge-tracking job hard. We could keep all the history in the client
(like svk!) and tracking merges would still be hard in the general
model we try to support.
The less obvious answer is "Subversion supports operations on things
other than 'the tree'". In the hg model, a project is a tree. Every
revision is a transformation on the entire tree. A branch is just a
different transformation on the same tree. All their simplicity
derives from this fact: revisions apply cleanly against their parents
because their parent is exactly the same. Subversion on the other
hand tries to support things like "read authorization" (where some
users can't see parts of the tree), "subtree checkouts" (where you can
do versioned operations on a small part of an enormous project without
ever needing to download data about the rest of the project), and
starting in 1.5 "depth-filtered operations" (commits, updates, diffs,
etc based on an arbitrary subtree of a tree).
The hg model makes these operations essentially impossible, and thus I
don't see how it can extend to truly enormous, interconnected
codebases where an individual user only needs to work on some parts of
it at a time, but that part may vary enormously among users. While it
might certainly be feasible for every user to locally have the entire
history of the subproject they are working on, it would not be
feasible for them to have the complete history of the entire codebase.
Thus the fundamental barrier to adoption of the Mercurial model is
not "no room to download the entire time dimension" but "no room to
download the entire space dimension".
You can see this clearly in our current merge tracking implementation;
one of the major complexities is "inherited mergeinfo". This concept
doesn't exist in the mercurial model, because it is fundamentally
about dealing with the repercussions of an operation on a subtree.
And while SVK does a reasonable job of merge tracking, it doesn't
actually support the entire Subversion model: it essentially places
tickets on the roots of branches and doesn't do a great job of
tracking merges that don't go between entire branches.
I don't mean this as a defense of the current merge-tracking
design/implementation. I'm just trying to point out that Subversion
is trying to solve a much more complicated problem than the newer
systems. For many use cases (for example, moderately sized open
source projects), the hg model is satisfactory. But extending their
model to cover all of Subversion's use cases seems to me as difficult
as extending Subversion to do merging as well as they do.
(Somehow, the world needs a version control system that supports the
changeset DAG concept *and* the subtrees-matter concept at the same
time. Perhaps that's what Subversion 2.0 needs to be. Or Mercurial
2.0. But neither one gets both concepts right in 1.0.)
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
Received on Sat Dec 1 20:50:20 2007