Slashdot Mirror

That's probably a side-effect of serving svn via Apache. http://svnbook.red-bean.com/en/1.0/ch06s04.html

Holy crap. You really have no idea on how to use Subversion, do you? As the previous poster said... take a little time to learn your tool, rather than blaming the tool. It is *always* a bad idea to check out the root like you're doing. Of *course* it will take several gigs if you also check out all the tags and branches.

Per project? The book covers that:
http://svnbook.red-bean.com/nightly/en/svn.branchm erge.maint.html#svn.branchmerge.maint.layout

Also, SVN doesn't -have- a way to rollback.

For many open source projects, finding good documentation is hard. In the case of Subversion, it couldn't be easier. In fact, the Subversion team has taken documentation to such a level that they should be considered THE model for documentation in the open source community. They have written a book (published in print by O'Reilly, but maintained and posted for free by them on the Internet) that documents their system, and it is very good. My job at the last company I worked for was to write wizards for the Eclipse platform that would automate several of the most common tasks that a Subversion user would try to do, and that book was the only reference I needed. You can find the book on their site here: http://svnbook.red-bean.com/ . They even do nightly builds of the book, so not only is their documentation complete and useful, it is also incredibly thorough and up to date.

If anyone on here hasn't read it, DO IT, because the first half will teach you why you want Subversion rather than CVS or some other alternative, and how to use it and how to get the most out of it (second half is lower level stuff you may not care about). It even includes best practices. Once you really learn how to use Subversion, you won't want to use anything else. And this is the way to get started.

Subversion fails to follow symbolic links that point to code that other projects share for the sake of a minority that still develops using Windows (which doesn't have real symbolic links).

I am an SVN newbie, but that kinda sounds like Externals.

RTFM: that is what the export command is for.

Hmm, when I read your post I thought I'd come here and suggest Subversion. Seems everyone else has done the same.

You really should use it. It's much easier to set up than you'd think, especially if you're on a Debian/Ubuntu box. If you use the file:/// syntax, you don't even need any kind of daemon or http server running; the client can do everything on its own. Say your thesis is currently sitting in ~/thesis, it's this easy to set up:

sudo apt-get install subversion
svnadmin create ~/thesisrepo
svn import ~/thesis file:///home/${USER}/thesisrepo -m "Initial import"
mv thesis thesisbackup
svn co file:///home/${USER}/thesisrepo thesis

That's it, you're done. ~/thesis is now a working copy of your repository, the repository itself (which will hold all versions of your files) is contained in ~/thesisrepo, and your original folder is backed up as ~/thesisbackup.

To work on your thesis, go into ~/thesis and start writing as you've always done. When you want to save a snapshot of the current state of your thesis (i.e. commit your changes), open a bash terminal, go into ~/thesis and type svn ci -m "some message". That's it. Much easier than running a backup; you can just stick it in a daily (even hourly) cron job. To back up all versions of the thesis on removable media, tar up the ~/thesisrepo folder and put it somewhere safe.

There's a bit more to know about it; namely you need to tell subversion when you add, remove, move or rename files. A good source for that is the Subversion Book, specifically Chapter 2.

I was kinda expecting this to be the first link...

Thanks for the excellent answer.

I'd actually like to steer clear of too many comparisons with Sharepoint, a clone will always be directly compared to Sharepoint, always living in it's shadow. Although most of your points are important though, a FLOSS product must provide an easy transition from any other system. Working with MS Office will be essential (although to get a feel for how the workflow will operate I thought OpenOffice would be best).

The current working title is: OpenDocumentPortal, how does that sound?

For the backend I've been looking at WebDAV with SVN and autocommit, for the frontend I'd like to create a Drupal Mod. The ideas here a great food for thought of course, I'm very interested to hear how others would do this project.

Passing around tarballs sounds silly until the only other option is Subversion.

Either you're joking, or you're lazy. Subversion is relatively easy to learn and certainly easier than trying to keep a bunch of tarballs in sync. Heck, everything you need to know about Subversion is in the very well written book, Version Control with Subversion. Once you've read it and understood how to work with Subversion, then tell me which is easier.

The error: permission denied on db/transactions/1-1.txn. And I can't figure out what it means. What permissions? Who's trying to access that? Why is it necessary? Why doesn't my user have those permissions when I attributed everything correctly?

Creating a Subversion repository is an incredibly simple task. The svnadmin utility, provided with Subversion, has a subcommand for doing just that. To create a new repository, just run: $ svnadmin create /path/to/repos

No, it's not that simple, and no it's not 'just run'. Where should the repositories reside? What are some normal defaults for this sort of situation? What do the authors recommend? What should the permissions of the repository paths be? What should the permissions of the repository root folder be? It's never 'just run'.

Subversion FAQ about Symbolic Links:

Does Subversion support symlinks?

Subversion 1.1 (and later) has the ability to put a symlink under version control, via the usual svn add command.

Details: the Subversion repository has no internal concept of a symlink. It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file.

You should also read up on Subversion External Definitions -- it looks as though you misunderstood how they really work.

What problems did you have with WebDAV and Windows? I've done only a little testing but it seemed to work ok for me. The only trouble I ran into was Windows XP's implementation, which rewrites WebDAV URL's (http://host/path/) into UNC paths (\\host\path\). As documented in the subversion book, this can be worked around by specifying the port number in the URL e.g http://host:80/path/, or https://host:443/path/

To explain it simply, decentralized systems allows me to have local intermidiate version of file. In centralized system, if I want my changes be protected or simply numbered (so I can rollback later), I have to commit working files into repository.

If my changes are at very very early stage and not yet ready for general use, commiting would force others to do additional steps to avoid using my new (raw, broken) version of file. If there are many commiters like that - and that's pretty normal with huge source code repositories - the life can easily become nightmare. (*)

I think these are the wrong reasons to use a decentralized solution. I don't know much about CVS, but SVN can easilly do what you're describing.

When I'm working, it often happens that I want to make a few changes which I want to be able to undo later. Usually this rollback will never actually happen, but killing my darlings can be difficult and the idea that my darlings are still somewhere safe in the revision history can be very dear.

However, if at this point my working copy is unstable, committing it could break the tree, now wouldn't you think?

Not with subversion, it won't:

~/working-copy/ $ svn cp http://svn/project/trunk/ http://svn/project/branches/my-experimental-branch /
~/working-copy/ $ svn switch http://svn/project/branches/my-experimental-branch /
~/working-copy/ $ svn commit # Done!

And the best of all is that its not stored on some obscure RAID-less laptop somewhere. Instead it is stored on that secure, central server which all developer teams need to have. If you don't have one yourself, there are some Subversion hosting companies.

This way you can always keep a stable trunk, which makes regular deployment or releases (tags) very straight-forward. Merging changes back and forth is also very straight-forward. The only disadvantage of SVN is that it doesn't support merge tracking yet, so it's good practise to track merges in the log or in some property (as svk does).

See the SVN book for more detailed information.

somehow i got the impression that locking a file while somebody is working on it isn't the best scneario.
copy-modify-merge is much more flexible solution (though it might be harder for binary files and might require specialised parsers)
more info here :
http://svnbook.red-bean.com/nightly/en/svn.basic.v sn-models.html

hmm. and how does subversion prevent you from doing that ?
i'm new to it, but i've found out that it supposedly allows to have mixed revisions in a single tree

http://svnbook.red-bean.com/nightly/en/svn.basic.i n-action.html#svn.basic.in-action.mixedrevs

1. branching is woefully inefficient on the storage side

2. merging is (practically) unsupported

3. there is no rollback from a commit, because....

4. it uses BerkeleyDB as the management system.. and that is bad because...

5. Oracle now own Sleepycat software (the makers of BDB)

- PeeCee

1. branching is woefully inefficient on the storage side

2. merging is (practically) unsupported

3. there is no rollback from a commit, because....

4. it uses BerkeleyDB as the management system.. and that is bad because...

5. Oracle now own Sleepycat software (the makers of BDB)

- PeeCee

1. branching is woefully inefficient on the storage side

2. merging is (practically) unsupported

3. there is no rollback from a commit, because....

4. it uses BerkeleyDB as the management system.. and that is bad because...

5. Oracle now own Sleepycat software (the makers of BDB)

- PeeCee

1. branching is woefully inefficient on the storage side

2. merging is (practically) unsupported

3. there is no rollback from a commit, because....

4. it uses BerkeleyDB as the management system.. and that is bad because...

5. Oracle now own Sleepycat software (the makers of BDB)

- PeeCee

http://svnbook.red-bean.com/nightly/en/svn.webdav. autoversioning.html

From the SVN Handbook:
"Because so many operating systems already have integrated WebDAV clients, the use case for this feature borders on fantastical: imagine an office of ordinary users running Microsoft Windows or Mac OS. Each user "mounts" the Subversion repository, which appears to be an ordinary network folder. They use the shared folder as they always do: open files, edit them, save them. Meanwhile, the server is automatically versioning everything. Any administrator (or knowledgeable user) can still use a Subversion client to search history and retrieve older versions of data."

Make them read this http://svnbook.red-bean.com/

Wait, scratch that... FORCE them to read it...

I've been using it (okay, I'm not in any Big Projects as we speak, but i've tried it), and it can be mostly simplified to svn update && svn commit for most of the time...

Now that is the old dispute between "lock, modify, unlock" and "copy, modify, merge" as outlined in the subversion book.

I think your points are valid, for some applications. And specifically for those where MS Office is also used.

Personally, I tend to favour the methodology of merging. If it's about a plain text source like code or LaTeX because I have experiences forgotten locks. The rare merging conficts are easily managed. One must keep in mind that the versioning system does not replace team communication. It's just a tool.

Now that is the old dispute between "lock, modify, unlock" and "copy, modify, merge" as outlined in the subversion book.

I think your points are valid, for some applications. And specifically for those where MS Office is also used.

Personally, I tend to favour the methodology of merging. If it's about a plain text source like code or LaTeX because I have experiences forgotten locks. The rare merging conficts are easily managed. One must keep in mind that the versioning system does not replace team communication. It's just a tool.

Now that is the old dispute between "lock, modify, unlock" and "copy, modify, merge" as outlined in the subversion book.

I think your points are valid, for some applications. And specifically for those where MS Office is also used.

Personally, I tend to favour the methodology of merging. If it's about a plain text source like code or LaTeX because I have experiences forgotten locks. The rare merging conficts are easily managed. One must keep in mind that the versioning system does not replace team communication. It's just a tool.

Because there's no journaling or shared-memory files being used, the repository can be safely accessed over a network filesystem and examined in a read-only environment.

So let me get this straight you been using subversion for two years but you can't be bothered with learning how to use it correctly and that's somehow subversion's problem... That's like blaming the hammer because it hit your thumb!!

Wanna try the fsfs backend:

#svnadmin create --fs-type fsfs /path/to/newrepos
#svnadmin dump /path/to/oldrepos | svnadmin load /path/to/newrepos

Ya that took me all of five minutes to find here:
http://svnbook.red-bean.com/nightly/en/svn.reposad min.html

You should also take a good long hard read of this section:
http://svnbook.red-bean.com/nightly/en/svn.reposad min.maint.html#svn.reposadmin.maint.cleanup
It'll help you with your clean up issues from the first post.

So let me get this straight you been using subversion for two years but you can't be bothered with learning how to use it correctly and that's somehow subversion's problem... That's like blaming the hammer because it hit your thumb!!

Wanna try the fsfs backend:

#svnadmin create --fs-type fsfs /path/to/newrepos
#svnadmin dump /path/to/oldrepos | svnadmin load /path/to/newrepos

Ya that took me all of five minutes to find here:
http://svnbook.red-bean.com/nightly/en/svn.reposad min.html

You should also take a good long hard read of this section:
http://svnbook.red-bean.com/nightly/en/svn.reposad min.maint.html#svn.reposadmin.maint.cleanup
It'll help you with your clean up issues from the first post.

No. I've used both (in fairly simple cases, admittedly), and SVN rules. In particular:

- It handles directories properly (renaming one in CVS requires you to add a new one and "delete" the old; and you can't actually delete directories.)
- The status system's far nicer. `svn status` gives you a complete rundown of the files in your project directory, which are modified, which new, which deleted, properties modified, and so on.
- (*NIX-only) You can include simlinks in the repository and they checkout AS simlinks...
- There's a nice on-line manual: http://svnbook.red-bean.com/

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

Sorry to go slighly off topic, and to do some lecturing myself, but I find it incredibly sad that we've (rather, the influence of the MPAA/RIAA and similar) have created a society that actual believes your statement above. That the absurdity of owning an idea as if it were tangible property is not apparent to everyone, but rather embraced by many if not the majority, almost brings me to tears over the future of civilized society. The really sad part is that this concept of private ownership goes well beyond existing IP laws. People don't actually "own" IP; the laws allow a limited (in time and extent) right of denial for copying, distributing, or implementing the IP depending on it's form. This limited monopoly is not an inherent right of ownership, but rather an incentive to publicize the IP so that others can learn from it and use it in the long run, thus benefiting society.

To quote Thomas Jefferson:

"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property."

A couple more things:

• Use subversion (correctly, maybe after reading the book: http://svnbook.red-bean.com/)
• Use Bugzilla (or Trac, but that isn't quite as good yet, OTOH it integrates with subversion; or use sugarcrm's bug tracking software, but again that isn't quite as polished)
• Make every new feature go through bugzilla as an enhancement.
• Never do more than one thing in a function (if your function requires more sentence structure than that of a 6 year old to describe what is happenning: you are doing too much)
• Head every function set with the following comments (consider using xml based versions of this that can be exported to an html page by using a generator):

//Summary:
// the 6 year old's description here
//Requires:
// name of each function and data type used here along whith the file they are located in
//Preconditions:
// the state expected for each variable that your function uses before the function begins
//Postconditions:
// the state of variables and the return value as the function completes
//Throws:
// possible exceptions thrown by the function

Carl Fogle?

Probably coincidence, but I bet Karl Fogel is not too happy about that.

I agree.

We use Subversion (see http://subversion.tigris.org/) with srvany (see http://www.iopus.com/guides/srvany.htm) at work on a Windows server and TortoiseSVN (http://tortoisesvn.tigris.org/) on the clients and it works very well for code *and* documents. I would use SVN version 1.2 as it handles binary files better by being able to lock files.

We find "svn:ignore" useful (http://svnbook.red-bean.com/en/1.1/svn-book.html# svn-ch-7-sect-2.3.3)
And "svn:needs-lock" (http://svnbook.red-bean.com/nightly/en/svn.advanc ed.locking.html)

I agree.

We use Subversion (see http://subversion.tigris.org/) with srvany (see http://www.iopus.com/guides/srvany.htm) at work on a Windows server and TortoiseSVN (http://tortoisesvn.tigris.org/) on the clients and it works very well for code *and* documents. I would use SVN version 1.2 as it handles binary files better by being able to lock files.

We find "svn:ignore" useful (http://svnbook.red-bean.com/en/1.1/svn-book.html# svn-ch-7-sect-2.3.3)
And "svn:needs-lock" (http://svnbook.red-bean.com/nightly/en/svn.advanc ed.locking.html)

Can you point to a particular line in the Linux kernel or Apache, for example, and identify who screwed it up?

Then there are the people who just don't care, or the excuse-makers who always blame the "impedance mismatch" between two pieces of code on the other guy or say that you can't apply traditional software-engineering standards when anyone who doesn't like it can change it themselves, etc. etc.

• People who just don't care about the code are more likely to be working for money in a closed-source proprietary environment, where there is the temptation to use obscure techniques to enhance job security, than they are to be contributing to a FOSS project.
• The "other guy" that people who blame the other guy would like to blame is likely to be known to the project lead, and better known than the excuse-maker. Shifting fault to another department "works" in an environment where functional software is merely an expendable means to an end, the true end being promostion within the system to a more rewarding position; because the customer is a captive, and has the choice of tolerating whatever disfunctional mess you provide or incurring the cost of changing to another system. It fails in FOSS; there is no other guy to blame, because after all you can identify the problem in whatever codebase it may lie and provide the patch; and the customer who despairs of your ever solving your organizational psychodrama has everything needed to begin a fork-with-less-crankiness.
• In FOSS, any compulsion to follow a software engineering principle arises from a desire to get your changes accepted by the maintainers, not from a desire for a promotion or fear of demotion. Maintainers who misjudge the balance between regulation and laxity will lack for contributors. In the closed proprietary environment, a programmer need please only the person who wields administrative authority (the ability to hire, fire, and adjust salary).

From Chapter 7 of Version Control with Subversion:

The servers file contains Subversion configuration options related to the network layers...

The section goes on to describe the http-proxy-host, http-proxy-port, http-proxy-username, and http-proxy-password options. So, "yes", it does support HTTP proxy, but not via WinInet (big surprise).

Another option would be to tunnel the SVN protocol over SSH (Subversion uses the "svn+ssh://" URL scheme for this).

I completely disagree with your option on using WebDAV versus "normal" GET/PUT. If your network admin has configured the proxy to disallow certain requests, using other protocol features to get around the restriction is not the answer. This is one of the things I hate about protocols like SOAP -- they actually make the proxy's life much more difficult.

Finally, why do you care what language the application is written in? The problems you describe would not "magically disappear" if Subversion were rewritten in Perl/Python/Ruby/Whatever.

I've looked it up and it seems that I was too ignorant about WebDAV concepts to say anything useful about its capabilities. Most of my vague ramblings were based on the following quote from the SVN book. I was basically just dreaming of a situation where you could mount a WebDAV URL and get to past revisions of files easily without having to explain as much to users as when using TurtoiseSVN, for example. I guess my users aren't the only people who need some explaining done to them ;-)

From the SVN book:

Can I view older revisions?

With an ordinary web browser? In one word: nope. At least, not with mod_dav_svn as your only tool.

Your web browser only speaks ordinary HTTP. That means it only knows how to GET public URLs, which represent the latest versions of files and directories. According to the WebDAV/DeltaV spec, each server defines a private URL syntax for older versions of resources, and that syntax is opaque to clients. To find an older version of a file, a client must follow a specific procedure to "discover" the proper URL; the procedure involves issuing a series of WebDAV PROPFIND requests and understanding DeltaV concepts. This is something your web browser simply can't do.

So to answer the question, one obvious way to see older revisions of files and directories is by passing the --revision argument to the svn list and svn cat commands. To browse old revisions with your web browser, however, you can use third-party software. A good example of this is ViewCVS (http://viewcvs.sourceforge.net/). ViewCVS was originally written to display CVS repositories through the web, and the latest bleeding-edge versions (at the time of writing) are able to understand Subversion repositories as well.

Perhaps you can use subversion external's?

You're absolutely spot on here. Look at the aewm project (a good reference implementation of an ICCCM compliant window manager), and then look at how many derivatives it has:

aewm++, alloywm, evilwm, maewm, Oroborus, phluid, Sapphire, swm, Clementine, WindowLab, YeahWM, Spook, wimpwm

Some of these are genuinely innovative but how many of them would exist if their authors had had to reimplement everything from scratch?

Pardon me if this is completely off-base, but I only switched from CVS to Subversion about a week ago.

Couldn't you use svn:externals to do what you want? I mean, couldn't you have a 'live' project or something that simply listed whatever tag you wanted in your externals? Then, whenever you get the 'live' site, it would get whichever tag was currently referenced?

Instructions are at http://svnbook.red-bean.com/en/1.0/ch07s03.html

A UI without drop shadows? It's incredibly fast and efficient? That sounds to me an awful lot like Window Maker, Openbox, Fluxbox, BlackBox, aewm, flwm, and about 1/2 million other window managers already available for Linux.

This guy's page says (basically) that if you have bad RAM, your repository can become corrupted. Well, no surprise there. With bad RAM, pretty much anything on your system can be corrupted. (That's another good reason to make backups.) This isn't exactly a mark against SVN.

Then he says "The moral of this story: Do not use binary file formats unless you can decode them and repair them". Of course, he also has GIF and PNG images on his website -- I wonder if he can decode and repair corrupted GIF and PNG files. I sure can't.

He says he's using CVS, so that "when shit happens (and shit happens) I will be able to repair it using, vi or emacs". Wow, good idea. Edit your repository's data files in vi -- that sounds safe.

This has been brought up before. Using a database to store data is not a crime. In fact, it's a really friggin' good idea.

Having no backups, and fixing the corruptions that occur (caused by bad hardware) using vi -- that's kind of sketchy.

It can be confusing.

AnkhSVN is a VS.NET plugin. However, I'd encourage you to check out the really excellent TortoiseSVN client. I think one of the main reasons people like IDE integration is they're so used to the extra hassle that first checking out, editing and remembering what files to checkin, that the lock-modify-unlock model imposes. With Subversion's copy-modify-merge model and TortoiseSVN's recursive-oriented commit dialog, I think tight IDE integration looses much of it's usefulness.

It can be confusing.

AnkhSVN is a VS.NET plugin. However, I'd encourage you to check out the really excellent TortoiseSVN client. I think one of the main reasons people like IDE integration is they're so used to the extra hassle that first checking out, editing and remembering what files to checkin, that the lock-modify-unlock model imposes. With Subversion's copy-modify-merge model and TortoiseSVN's recursive-oriented commit dialog, I think tight IDE integration looses much of it's usefulness.

Can't tell if you're trolling, but this being a Subversion story and all, try googling it.

You could even try reading the fine Subversion red manual. Note that, for a simple setup using the file based repository (FSFS), you don't need any fancy-dan Apache or BDB, just subversion itself.

• The first edition of the classic Cheswick and Bellovin book Firewalls and Internet Security: Repelling the Wily Hacker is available in its entirety for free online.
• Black Box Voting - Chapter 01 Chapter 02 Chapter 03 Chapter 04 Chapter 05 Chapter 06 Chapter 07 Chapter 08 Chapter 09 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 d - Appendix Footnotes Index
• http://www.physicsforfree.com/
• http://www.dctech.com/physics/textbooks.php
• http://www.nap.edu/books/NX005722/html/related.htm l
• High Energy Physics - Fields
• Also, the National Academies Press says it has over 2,500 books on many different academic topics online for free.
• Open Source Development with CVS

Cory Doctorow:

Eastern Standard Tribe (CC)
A Place So Foreign (and eight more) (CC)
Down and Out in the Magic Kingdom (CC)

Lawrence Lessig:

Free Culture

Tech and science books:

Version Control with Subversion (CC)
An open source math book
Light and Matter, a series of physics texts by Ben Crowell

Lists:
The Assayer is a place to find and review open books.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.