[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-07-01 02:03:27 CEST

Branko Čibej <brane@xbc.nu> writes:
> 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.

Brane, we are so much in agreement here that airport security is
having trouble telling us apart.

On July 24th, I'm talking a bit at the O'Reilly Radar Executive
Briefing (http://conferences.oreillynet.com/pub/w/58/radar.html) about
Subversion and version control in general. When O'Reilly asked me to
suggest some topics, I offered the following:

   - Why it's important to be able to search the change history for
     Wikipedia entries (and why it's incredibly cumbersome using
     today's interface);

   - Why the U.S. Congress needs real version control tools (and why
     it's our own fault for not providing them);

   - Why good version tracking is important in a world where more and
     more creativity consists of mixing existing things together.

I think Subversion stands a better chance of achieving this kind of
ubiquity (or being part of something that achieves it) than many

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

... *better* *merge* *tools* ...

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


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

Yup, I sometimes encounter that reaction too, when explaining
Subversion to non-programmers who have to do document revision control
in their daily work (artists, editors, lawyers, civil servants, etc).

On the other hand, I've lately been watching some version control
newbies -- the volunteer translators of my book -- struggle with
Subversion. Without TortoiseSVN, they'd be completely sunk. As it
is, some of them are just barely treading water. I still have to give
technical support sometimes: for example, they're mostly working in
teams of two or more, and recently one of the teams encountered its
first conflict. It took several emails to explain what was going on
and how to resolve it.

It's been a sobering experience; we've a long way to go, I think.


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