[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: Branko ─îibej <brane_at_xbc.nu>
Date: 2007-07-01 01:38:55 CEST

Thank you, Karl! Beautifully put, as usual.

> 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.

I'd like to take this one step further:

    Version control must become ubiquitous.

In other words: We must aim towards the day when everybody uses version
control all the time, without having to think about it.


Consider: Not so long ago, many widely-used computers did not have the
concept of a file system; or if they did, it was not hierarchic. The
argument then was that users didn't need that organizing power, as they
didn't have that much information to organize. (Instead, we invented
interesting labelling schemes to keep the cassette tapes containing our
data marginally organized).

Consider: Not so long ago,, many widely-used computers did not have the
concept of multitasking, or if they did, it was done in a way that
practically required manual context switching. The argument then was
that users didn't need that concurrency, since they could only use one
program at a time.

(And people who did have access to real multitasking OSes with real
filesystems, e.g., RSX-11, TOPS-10, and later VMS and Unix, were often
in danger of bursting their guts for laughing when they heard such
arguments. Did you hear the one about 8-bit registers being good enough
for most applications?)

From today's perspective, these anecdotes sound a bit like a museum
guide expounding on the technological revolution brought on by the
palaeolithic hammerstone. And the list of such anecdotes is endless.

These days, version control is generally accepted by a large, or at
least vocal, minority of programmers as "the thing to do." And I stress:
*minority*. Too many programmers still view version control as extra
work that's imposed on them for no visible benefit. (Well, heh, too many
programmers also view software engineering as extra work with no visible

So we knurds all have hammerstones, and some of us even prefer using
them over teeth -- or foreheads -- for cracking our nuts, despite the
mashed fingers that sometimes result from their unwary application.

But what about everyone else? We keep hearing and talking about version
control in the context of software development. Some even prefer the
term "source control," as if program source it the only artefact that
merits versioning. And everyone else can eat their mammoth haunch raw,
because fire is only for shamans. ...

No! Being able to see the history of one's work should be as implicit as
saving said work in a named file that can be manipulated separately from
the application that created it -- or having on one's desk a box with a
dual-core CPU, real-time, true-colour 3D graphics, and a multitasking
OS. And I believe the Subversion community is an ideal nurturing ground
for such a concept, precisely because it is so uncommonly user-centric.
Let us therefore stop trying to take over the world -- and subvert it

-- Brane

P.S.: The other day, an architect was complaining to me about how hard
and error-prone it is to keep track of different versions of his
projects. So I gave a small demonstration with Subversion and WebDAV
auto-commit. If I may allow myself a bit of an understatement: the man
found the concept of automatic version control quite interesting, and
was intrigued by the circumstance that his multi-kilobuck drafting tools
don't support it. Actually, "slavering" and "raving mad" would be apt
descriptions of his reactions. ...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 1 01:39:08 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.