[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion, decentralized version control, and the future.

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-06-30 09:18:07 CEST

Karl Fogel wrote:
> True decentralized systems are really hard for most people to wrap
> their heads around.

That's maybe the biggest advantage Subversion has now over those
decentralized systems. There still are thousands of companies which
don't use or sometimes never even heard of version control (maybe hard
to believe for you guys, but it is true - in my area, I think not even
20% of all companies which do some kind of SW development don't use
version control at all). If you try to explain to those why they need
version control, they will easily understand that. But then comes the
time to choose a system, and that's when they simply reject
decentralized systems: they are too far away from their current working
cycle. Subversion on the other hand can be configured and set up so they
don't have to change their working cycle too much. So that is what most
of them choose.

> One of Subversion's flaws (mea culpa) is that we didn't realize the
> usefulness of having symmetrical functionality on the client and
> server sides. The working copy should really be a repository, even if
> it's not always going to store all the history available on the server
> side (with some projects, you really can't, it's too big).

I agree here. The more information is available offline, the better.
Because offline is faster. In TortoiseSVN, Stefan Fuhrmann has
implemented a cache for log messages (my Kudos for that btw) because it
is simply too slow to get them from the repository every time you need
them, especially for bigger projects.

> We also have to be faster. Fortunately, we've pretty much agreed,
> IIRC, that we're willing to punt on subdirectory detachability in
> working copies in order to get performance improvements.

That may be one of the biggest improvements where users will see
immediately the performance gain.

> Subversion's phenomenal adoption rate (*) isn't due to being the only
> game in town. We never were, if you count the proprietary systems,
> and we're even less so now that the open source version control world
> has become so fertile. The reason Subversion is taking over the world
> is because it is tremendously user-focused, and because it provides
> well-documented APIs that enable other developers to write software on
> top of Subversion. We should copy what we need from the decentralized
> systems, but remember that most users don't know or care whether a
> system is centralized or decentralized -- their ideal system is one
> they don't notice. Let's keep our eye on the ball, so they don't have
> to.

Also never forget that for a high adoption rate, you need good UI
clients. Yes, command line clients are used too. But most Windows users
simply refuse to work with those. If a company has to choose a version
control system, they not only look at the features and speed, they also
look at what UI clients there are and how they perform. If there are no
UI clients or no good ones, that's a big minus point and it *will*
influence their decision for the version control system.

Another big plus for Subversion is that it was designed to also work on
Windows. That means there are no (or almost none (1)) ugly hacks in
there to make it work on Windows - something most decentralized systems
have (if they even work on Windows at all). Even Mercurial wasn't
designed to work on Windows when it started from what I've seen (2). And
Git, well I think it will never work on Windows in a way that it's
usable (3).
Some people think that Windows is not important and hope it will get
replaced by a free OS anyway. But that won't happen anytime soon. The
reality simply is that most people have to use Windows at work and
therefore need a version control system which works there well.

In this thread, there already were some discussions about which language
to use for Subversion 2.0. Even though I think it's too early to discuss
this because the first step would be to specify the features and
requirements first, I'd like to throw in some important facts which
should be considered when the time to choose the language arrives:
In order to get a lot of UI clients (see above why UI clients are
important), it's not enough to have a language that many people
understand and can work with. It's also important to have a library in a
language that can be used everywhere. Languages which require some kind
of environment they run in (usually languages which have garbage
collection) can't be used for plugins. At least not without unsolvable
incompatibility problems. A good explanation on what happens if you e.g.
write a shell extension plugin in .NET can be found here (4). And I'm
sure the same applies to other high level languages. And of course not
only for shell plugins but for plugins for any other application (say IDEs).
So when the time comes to choose a language, please consider these
problems too.

Stefan

(1)
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/io.c?revision=8341&view=markup
(2) http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
     needed for line-ending conversions. Subversion is much better here
     because you can decide for every file, not just by file extension
     what line endings to use.
(3) http://marc.info/?l=git&m=114131099531633
(4) http://blogs.msdn.com/oldnewthing/archive/2006/12/18/1317290.aspx

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 30 09:18:48 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.