Branko Čibej <brane@xbc.nu> writes:
> 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?
I think this is rather too pessimistic.
- sparse directories
- interactive conflict resolution (not original to us, of course)
- relative svn:externals
Of course, the big feature is merge-tracking, and I think your
complaints there are fair, but a large part of the delay is that we're
trying to hit more use cases right out of the gate (e.g., truly
arbitrary cherry-picking).
> 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.
That I can't agree with. We didn't spend *so* much time on that, and
a lot of what we did is stuff that any project would have to do once
it achieves a certain level of popularity. (There were some genuine
identity confusion problems going on -- ones that could actually hurt
users -- before we started getting serious about trademarks, as you
know.)
> 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.
If I were setting up a system for an open source project to use, I'd
have to examine a lot of factors (not just hot air, btw: for some
time, I've been advocating that the FSF switch GNU Emacs from CVS to
Git or Mercurial, because those would likely be the best tools for
that particular job).
But for enterprise-level version control, across a large organization
and a diverse set of users? Subversion, no question about it.
> 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 [...]
Well, that's what we're trying to do. I understand that your mail is
meant to be constructive, but a... little more specificity would be
helpful :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 3 01:11:36 2007