Slashdot Mirror
Subversion 1.0 Released
Phil John writes "Subversion 1.0 has finally been released. The people who maintain CVS have given us a viable replacement for our de-facto (and aged) versioning system. If you're new to Subversion its feature list looks like fixes for everything that is wrong in CVS, renaming, directory structure and metadata version tracking, file deletion, proper management of binary files and it's pretty portable to boot." According to the download page, binaries may take a few days to appear.
It's not released under the Apache/BSD License . . .
It's released under an Apache Style license.
Google Cache since the site seems to be dying as we speak.
Your hair look like poop, Bob! - Wanker.
There is always GNU arch. It's got some nice features that subversion does not have to boot! Such as distributed repositories, advanced merging, and GPG signed patches.
Here you go, lazy ass
I've been using earlier builds for my own codebase stuff, and while there are a few new concepts to get your head around, overall the system works very well. I haven't had any problems with corruption or loss, and everything I've needed to do has worked perfectly.
My congrats to the dev team for a good solid product.
For those looking to use it, befor eyou do, work out your versioned directory structure, it *is* kinda important (although not critical, you can move things around afterwards). For example, I have:
trunk/(project name)
tag/(project name)/(tag)
branch/(project name)/(branch name)
as my general layout. Other people may have other recommendations, but tags and branches etc are no longer this explicit thing, its just about where you put them in the "filesystem".
try this.
:)
Note: written by a subversion dev
Here's a comparison with 10 popular replacements
n .html
http://better-scm.berlios.de/comparison/compariso
Quasi-Mirror Didn't get the style-sheets, so the formatting is a bit whack.
Your hair look like poop, Bob! - Wanker.
This news post really does nothing to explain why Subversion is so much better than CVS.
Subversion is, in essence, a reimplementation of CVS without the limitations of CVS.
It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.
This is, IMHO, reason enough to switch. (And was reason enough to switch for me a while ago.)
SVN can do binary-file diffs, tracks submissions of multiple files as part of the same revision, and if memory serves me correctly, does O(1) branching and tagging.
For those of you who, like me, use TortoiseCVS to do version control in windows, there is TortoiseSVN which works like a charm and provides all the functionality you're using in TortoiseCVS with some nice extras.
I could go on at great length, but the Subversion team can probably do a much better job explaining this than I can, so go to their web site instead.
Quite honestly, I think that Subversion is so much superior to CVS that it will completely replace it, and I haven't got anything to do with the project. Once I switched over, I never looked back.
1.0 release means that SVN now supports everything that CVS does, with a few extras. From here, they are planning to work on new features.
I've heard some bellyaching over the license already (boo hoo). BSD code is Gratis and Libre, and if the Subversion team isn't losing sleep over MicroSomeone ha>oring their project into one of their own, I won't either.
Please don't turn this discussion into another license vs. license argument, and have a look at the project for its real merit.
"The wise man proportions his belief to the evidence." -- David Hume
The main site seems to be slashdotted. There appears to be an online book on the subject here
Version Control with Subversion
Draft Revision 8770
Ben Collins-Sussman
Brian W. Fitzpatrick
C. Michael Pilato
-jim
According to their website, Subversion also supports a standalone server mode, much like cvs pserver/ssh.
Yes, because it uses WebDAV for file transfers. This requires more overhead obviously, but it also makes it more extensible.
I don't want to sell anything, buy anything, or process anything. I don't want to sell anything bought or processed...
Just like WebDAV is an extension of HTTP 1.1, Subversion is an extension of the WebDAV protocol. This means that:
* It can run as an Apache module or a standalone server
* It can go anywhere HTTP goes (including caching proxies) as it runs entirely over port 80 with WebDAVish calls.
* It implements part of the WebDAV protocol, and in the future might fully implement it meaning seamless integration in to software like Macromedia Dreamweaver.
* Uses Apache for the authentication, so you can authenticate with any module you find/write.
Right now our WSU Linux User Group is using Subversion for development. Authentication is tied to a PostgreSQL backend that is shared with the Zope/Plone server, so an admin can login to the Member panel and add/remove people from the developer group to give or take Subversion access. A real WebDAV folder is also setup that shares the same authentication method. Now we just have to tie in mail server and ssh authing...
http://www.red-bean.com/sussman/svn-anti-fud.html
Also, #svn channel on freenode irc is helpful.
The New Breed of Version Control Systems
Arch doesn't require any accounts for read-only access. Write access requires 1 account at minimum. If you want to have multiple people use the same account, that will work fine. (I'd recommend using ssh public-key authentication, though, since shared passwords are always bad policy)
Supported write protocols include webdav, sftp (the one that's part of ssh) and ftp. Shell access is never required.
It's possible, through a variety of easily-made missteps, for a file to lose the tag that marks it as binary. Suddenly, fresh checkouts of the file have newline translations done on them, and all hell breaks loose. And, if you edit the ,v file that stores the revision history, you'll discover that the binary file is actually stored as a raw byte range within a text file.
So, yeah, RCS supports binary files. It just doesn't do it very well.
Schwab
Editor, A1-AAA AmeriCaptions
CVS has nothing to with sharing code (although it can be used for that, but that's not its primary purpose). CVS is a version control system, more akin to something like Visual Source Safe.
Basically, it serves two functions. First, it tracks changes made to files in your source tree, so that if the latest tracked version of a particular piece of code is broken, you can compare it to or even roll back to an older version of the code to either work around or diagnose what broke. Second, it allows multiple users to work on the same file at the same time without stepping on each others toes too much. This works by having each user check out a copy of the code from the main repository which contains the "master" copies of the code. When they're done working on the code they can check it back in to the repository where (often with a little human intervention) the changes are merged with the most recent copy stashed in the repository.
Part of that does involve a central server to store repository in -- on a local network this is could often be a commonly accessable directory or mounted drive off of a WinServer/SMB or NFS server. CVS also allows for internet checkouts and checkins, which is how a lot of open source stuff is handled.
CVS and other version control programs have lots of other features I haven't mentioned here, such as branches, labels, etc., but I figured this gives you a good idea of what's going on.
Hope this helps.
Here's the overview from the manual.
...you could do a lot worse than TortoiseSVN (also on tigris.org). It's an explorer shell plugin with icon overlays. Open up windows explorer, right click files to comit and whoosh...it's done.
Also has a visual diff and all sorts of other goodies in it too. There's also a (somewhat unrelated) project of the same ilk for CVS called, unsurprisingly, TortoiseCVS (different developers IIRC, same idea though, hence the similar name).
I've been using Subversion for the last 6 months and TortoiseSVN for the last 5, never had any data corruption or borked repositories, it Just Works(tm).
What I like is that the developers started eating their own dogfood fairly early on and have been self hosting for a fair while now, so that shows you how much faith they have in the system.
I am NaN
I think slashdot may have jumped the gun here, and I hope that the slashdotting of their web server is not going to cause them problems with actually getting 1.0 out the door, which is supposed to happen sometime Monday (timezone unknown).
see shy jo
Name a single counterexample of a GPL'd library shipped as part of a commercial OS.
Let's take two examples here: first, zlib. It was released under the BSD licence, not GPL, because it was important to wean people off the LZW-patent-encumbred compress. And it made it to commercial systems. But take, on the other hand, the readline library. This could have been immensely useful to a lot of commercial vendors, and Stallman knew it, so he used the GPL (not even LGPL) to try and "force" third party code to be GPL'd. As a result, nobody outside the free software world uses it.
there's already an eclipse plugin available.
I am NaN
1. Subversion does NOT require Apache. It can use either Apache OR svnserve as its network server.
d .html
2. Want decentralized subversion? Check out the svk project at http://svk.elixus.org/
3. Best benefits over CVS? Well, its basically a 4-year redesign/rewrite/replacement of cvs by people very familiar with cvs (ie wrote the book on cvs and runs a company specializing in cvs services).
a. Cheap copies (constant time, store diffs only so branch often if you want even on very large projects).
b. Directories and metadata are versioned too.
c. You can move files and directories without losing history.
d. Atomic commits! Issue a bunch of "add" commands, then a "commit". The whole thing rolls back if any of it fails and the revision is per commit (not file).
e. Other benefits may be more important to you than these (but these were enough for me to switch from cvs to svn).
4. Is svn 1.0 ready for prime-time? Subversion project has been hosting itself for almost 2 years now and they never lost any code. For the ultra-paranoid, you can configure it to keep all bsdb logs so you can roll back every transaction since the beginning of your repository creation (but that would be silly).
Don't forget to see:
http://www.red-bean.com/sussman/svn-anti-fu
And irc: #svn on freenode
For example, there's also a supported custom network protocol server (svnserve, uses "svn://" URIs) for those that don't/can't maintain Apache w/mod_dav.
(And everything else people say about how cool Subversion is -- is true! Really, check it out. Sourceforge should switch over ASAP.)
That's because everyone else uses softlinks to do that. Windows doesn't have softlinks (shortcuts aren't softlinks), so SourceUnSafe had to hack on "sharing" to make up for it.
Schwab
Editor, A1-AAA AmeriCaptions
Subversion can be centralized (used as-is) or it can be decentralized (used with svk).
More info on svk: http://svk.elixus.org/
The beauty of being designed from the ground up to be a set of C APIs allows it to be used in any way you want.
For me, I like using it with ViewCVS and TortoiseSVN (similar to the awesome TortoiseCVS extention to Windows Explorer).
Yes. From the "Version Control with Subversion" book:
After fourteen months of coding, Subversion became "self-hosting" on August 31, 2001. That is, Subversion developers stopped using CVS to manage Subversion's own source code, and started using Subversion instead.
Actually, Windows does support softlinks, which are termed as junctions. See http://www.sysinternals.com/ntw2k/source/misc.shtm l#junction for more information.
Yes! And it rocks. Once setup commands are simple and so much better then cvs. For example a current anonymous checkout from sourceforge requires the following commands.While the subversion command would beThat in itself is enough to sell me.
See for yourself. Setup takes just a few minutes.
Although I can't speak for the current version, I can say that it was either impossible or very difficult to compile using mingw32/msys several months back. Unless you're up for some pain, you probably ought to just wait for the binaries.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
You're both kind of right.
Technically, NTFS supports both soft and hard links.
From a practical I-want-to-have-software-using-it standpoint, Windows doesn't have support for either, just shortcuts.
May we never see th
Not even Microsoft uses Source Safe -- they use something called Source Depot which I heard is based on Perforce or something.
Explorer only creates Explorer style Shortcuts, whether in NT 2K which has something more similar to symlinks, or in Win95, WinNT4 which didn't. The real symlinks have to be created in other ways.
The stupid thing is MS could have implemented real kernel level symlinks in the jump to Win95, but they didn't. They instead made Shortcuts at the shell level. Apple got it right with System 7 Aliases, which were symlinks at the kernel level.
First, it tracks changes made to files in your source tree [...]
While CVS tracks changes made to individual _files_ in the source tree, some other revision control systems (ie. Arch, BitKeeper, etc) store changes to the tree state atomically. That is to say, if you have file1.c and file1.h and you make a change that touches both of them, you can bundle both those changes together into one atomic operation, so that they show up as just one changelog entry and that every developer who applies one of these changes always gets both of them.
In CVS, to know that file1.c version 1.13 and file1.h version 1.2 both belong in the same tree, you need to "tag" each file in the tree -- adding notation to the backend store for each individual file indicating that they both are tied to THIS_TAG_VERSION. In the case of a changeset-oriented system, on the other hand, the appropriate version of both files is just another element of the repository state -- so instead of a set of individual file states, you just have one big repository state that holds everything together.
This also makes updates very fast, since instead of checking for each file "is there an updated version of this file?" for each and every file in the repository, you can just check "are there new patches for this repository?" and download that.
There are other things one can reasonably expect of a modern revision control system, as well. For instance, a site using tla-pqm to manage their Arch repository can be set up such that only code which compiles and passes the unit tests can be merged into the primary repository; this is exceedingly good practice, especially on big teams.
Another nifty thing good revision control systems can do (well, some of them -- Subversion, for instance, lacks this) is distributed operation. For instance, this means you can make a branch of someone else's code stored on your own server, make revision-controlled changes on that server, and then ask them to merge your changes back into their branch -- without yourself having any access to their server at all! Distributed branching, in combination with good branch and merge operators, enable quite a lot of workflows that would otherwise be quite impractical. In terms of release-quality revision control systems, the only two that really have this support are Arch and BitKeeper (svk and darcs do something similar, but neither is exactly mature or in posession of a substantial userbase; that said, I think darcs is quite interesting from a research-project point of view).
By the way, I'm currently the maintainer of cscvs (a tool for building a SQLite database with inferred changeset information from analyzing a CVS repository's history, and then doing interesting things in it -- ranging from reporting to importing the archive into Arch), making me an interesting combination of "informed" and "biased" in this discussion. If you're interested in revision control and possibly interested in a continuation of this rant (or disagree with some part of it), please drop me an email.
I haven't checked recently but it is unlikely. When I tried to convince the subversion devs a few years back that such functionality would be a good thing (i.e. offer the choice, let users weight the risks and benefits and make their own decisions) the idea was pretty thorougly shot down by all. I doubt anything has changed their minds in the time since.
Personally I don't see the difference between this kind of source code transformation and the more accepted RCS keyword kind. Except this has the immediately obvious benefit of obviating all of the stupid source code style issues known to mankind and letting people use whatever they prefer transparently.
You have 3 different places to hook into the commit cycle in version 1.0:
- startcommit
- pre-commit
- post-commit
start-commit is passed the repository and the user, pre-commit is passed the repository and the name of the transaction (which can be examined with svnlook), and post-commit is passed the repository and the revision number. If either start-commit or pre-commit fail, the commit is rolled back; post-commit exit status is ignored.Before the transaction begins, you can prequalify the user for commit privs
After the transaction tree has been completely built, but before it's actually committed to the repository
After the entire commit cycle is completed
This could be used to canonize it coming in... it would be up to the user to reformat it coming out if desired... but everything would then get flagged as locally modified... though the user could always recanonize the code before committing... which defeats your goal of automating it all:)
So, the grail is closer, but as always, just out of reach.
Heh -- having been on the Arch list for a while, I distinctly recall watching the feature requests from Linux kernel developers ("we need $THIS before we can migrate away from BitKeeper" sort of thing).
Their objections (other than performance, which has been dramatically improved lately) have been largely silly things, not related to the Arch core itself (which is most excellently designed; thanks Tom!), but rather mostly UI-type issues ("we want built-in a graphical 3-way merge tool!" type items).
That's the case for Arch, anyhow. As for the post you just mentioned, its objections to SVN happen to be things that either don't hinder Arch at all or should be non-issues altogether (ie. better solution available):
1. Equivalent to cvsup. Arch has this functionality built in, implicit in its mirroring and distributed support features.
2. Support for (user-supplied) keywords. The general consensus on the Arch list is that it's a bad idea for any revision control system to support this "feature" at all, and that there are better ways to do anything one could want them for.
3. Converting the repository -- cscvs, a tool I help to maintain, does just that.
We haven't announced 1.0 just yet; we're going to do it sometime on Monday the 23rd. The Subversion team prepped the website and rolled a 'beta' 1.0 tarball over the weekend in preparation for Monday. We wanted to make sure there were no embarrassing bugs in the tarball itself (i.e. no "brown bag" releases due to a bad libtool or something!)
Thanks for all the nice comments. Stay tuned for the official announcement.
Arch has some very nice features, probably too many. It's so powerful that it scares people off.
Octopy looks like a promising qt gui frontend for arch to solve that problem.
Apache access is completely optional. It has its uses for people, such as a security using Apache instead of just the basic unix permissions. Its definitely slower than using the native protocol for svnserve. It solves all of CVS's problems. However like all software, it has its own problems. At least in SVN's case the code is realtively clean and organized, so changing it will be much easier. Ever look at CVS code? Pure spaghetti.
You don't want atomic commits you want changeset
functionality. Just so the terminology is in tune
with others. And subversion seems to have partial
support for that. If you figure out what "implicit
changeset" functionality is exactly...
I thought I had the same problem with subversion -- Until I discovered it was my fault.
/home/svn, and added everyone who needed access to the svn group.
/home/svn' every few days which drove me insane.
3 .htm l#svn-ch-6-sidebar-1
I had given local accounts to about 5 developers on my machine. They all used svn+ssh to access the repository. I had created a 'svn' user and group, put the repository in
This is not the way to do it.
Berkely DB is a transactional database; it will not necessarily work properly if multiple processes are accessing it at the same time. I ended up having to do a 'svnadmin recover
The solution is to drop svn+ssh, and run svnserve. That's what I did. Of course, apache2 can be run also, but that was too much for my needs.
For more details, check out the subversion book, chapter 6.
http://svnbook.red-bean.com/html-chunk/ch06s0
One of the developers took me through a more detailed explanation of why it was a bad idea to use svn+ssh with multiple developers. Suffice to say, since I've moved to svnserve, I have had absolutely not a single problem.
If anybody's wondering about how long it takes to switch from CVS: it's about half an hour before you see it start to pay off.
And if you're used to using CVS through ssh, it's even easier with SVN: svn co svn+ssh:///host/path/to/repos/trunk repos
All that's left to do is get used to the different keys. Oh, and instead of doing a 'svn up' before committing, use 'svn status' -- it actually does something useful.
I don't see a compelling reason not to switch.
Your sysadmin sucks.
There is: AnkhSVN.
VS.NET plugin. (project page, with downloads, normally here but currently blown away by the load. Maybe grab it from the Google cache of the page but that too seems to be overloaded. Oh well. You could always use TortoiseSVN instead.)
There was an old VC++ plugin "Subway" but it sucks.
Remember that what's inside of you doesn't matter because nobody can see it.
You also don't have to have apache2 or any of that -- svnserve works perfectly well, and ssh access doesn't require any server at all (similar to CVS).
Not sure why the original poster said Subversion came from "the people who maintain CVS". They are two separate developer groups -- as far as I know there is no overlap between the currently active developers of CVS and Subversion.
:-). Subversion 1.0 wasn't actually out yet when he posted. We had released a beta prerelease, and were careful to say that 1.0 itself wouldn't be out till Monday. Oh well, win some, lose some.
Also, he was early
Anyway, it's almost Monday now, so check back soon at http://subversion.tigris.org/.
http://www.red-bean.com/kfogel
I had such a fun time the other day installing BerkeleyDB 4.2, Apache 2.0.48, and Subversion 0.37 from source. It just took me way too long to figure out the right configuration options to get the Subversion server installed correctly, so here are my notes. They're mostly stolen from somewhere on the Web (don't remember where), modified a bit with things I learned along the way. If this is useful to you, great.
../dist/configure
/usr/local/BerkeleyDB.4.2
./configure --enable-dav=static --enable-so=static --with-dbm=db4 --with-berkeley-db=/usr/local/BerkeleyDB.4.2
./configure --with-berkeley-db=/usr/local/BerkeleyDB.4.2
/repos> /absolute/path/to/repository
1) Download, build, and install Berkeley 4.2.52 with the default location; this is as simple as:
$ cd db-4.2.52/build_unix
$
$ make
$ su
# make install
make sure LD_LIBRARY_PATH includes
2) Download Apache 2.0.48 tarball and build it with the defaults:
$ cd httpd-2.0.48
$
$ make
$ su
# make install
3) Download a Subversion tarball (e.g. subversion-0.37.0.tar.gz) since that comes fully formed:
$ cd subversion-0.37.0
$
$ make
$ su
# make install
And then follow the directions for configuring Apache, which could be as simple as adding the following:
<Location
DAV svn
SVNPath
</Location>
Use Ctrl-C instead of ESC in Vim!
- direct, local access
- HTTP access using WebDAV (RFC 2518) and Delta-V (RFC 3523)
- custom Subversion network protocol
While there is some theoretical elegance to using WebDAV with Delta-V, in practice I've found that the custom Subversion network protocol is easier to set up and use, and more robust. It can be used either directly for anonymous read-only access, or tunnelled through SSH for read/write access.I have twelve free software projects in Subversion repositories, and I've been quite happy with it.
Doubt it - one of Bitkeeper's key features is it's peer to peer. Each developer has a clone of the repository. Changes are committed to the developer's local repository first before propogating to the parent repository. svn doesn't work like this.
"The distributed tree model is also another problem. I'm sure that for Linux kernel development, arch makes sense. For a commercial product we do not want multiple trees. We want one consistent tree so when we go to a customer site we don't have to wonder why a circuit is malfunctioning because we didn't sync up with Jack's tree or whatever. We rejected BitKeeper on the same grounds; we weren't so much against paying but wanted something with the right feature set."
Just for the record, just because BitKeeper supports (and works great) in a fully distributed environment, doesn't mean you need to use it that way. Every developer can simply clone, then push each change back to the parent, and it would work like a centralized server.
If your developer "forgets" to push, that's no different in a distributed than a centralized system... once pushed, everyone has access to it.
There are other advantages to distributed operation too, mostly in failure tolerance and disconnected operation... BitKeeper is the only tool out there I am aware of that lets you work completely via floppy disks, without losing any functionality (it maintains its checksummed changeset model)
--eric
More data, damnit!
We never had a single hung repository that requried svnadmin recover except when the power went out and our generator didn't kick on and the UPS batteries drained. FWIW we do use Apache 2 and DAV for our repository access.
Our primary tree (source code) is around 20MB including all deltified versions (basically our 'strings' table). We also have separate repositories for our corporate website and for internal documents, etc. All totalling we have about 50MB of versioned data -- all of it precious and have never lost a single byte.
Oh, one last thing. We've been using SVN for our non-source tree for a longer time period so we've really been using SVN for almost 7 months now with lots of changes from multiple developers on multiple platforms.
If you like the CVS model of development (non-change-sets) then you'll like SVN. If you want distributed development then try an add-on to SVN called SVK.
But as far as the different tree model: we simply do not want this. We don't have any fault tolerance issues. We have some distributed developers but since our code is intimately tied to physical hardware its a moot point for us.
If we don't have network connectivity to our target hardware lab we got bigger problems. But we also don't want people maintaining their own trees and branches.
There are some other things that we liked about SVN. The fact that its supported by a logged DB engine. That was another critical blow for arch to us. If a server went down during the middle of a commit we could have corrupted files. Internally we use XFS which journals metadata but not user data. Its actually silly for a file system to do this since the FS has no clue about where transaction boundaries are.
So if we had say a HW failure with arch we could have a complete tree with some corrupted files. SVN physically logs the data to disk and then fsync()s the logs and then writes them in the database.
But BK is a nice product and I like Larry McVoy, our choice of SVN stemed from many little things.
Yes, I can confirm that. We're working with SubVersion for almost one year now, and it's a really reliable version control system. I simply love it :-)
:-)
The only problems we've had so far were due to bugs in the Berkeley DataBase which were resolved simply by upgrading BDB and SubVersion.
The beauty of SubVersion is its speed compared to CVS and low diskfootprint when it comes to versioning binaries. In CVS, every change to a binary file causes the complete new version of the file to be appended in the repository (AFAIK). Thus, if you change a 10kB binary file five times, the RCS file will be about 50kB. Not so in SubVersion, it handles binaries very efficient.
Another speed-issue of CVS is that when you're working remotely your whole working copy needs to be transmitted to the server and the server checks what changed. Obviously this is a bandwidth and time eater. SubVersion stores a copy of the last checked out version on your disk and thus already knows what changed and only transmits these changes. This means your working copy is always double the size but this trade-off is one of the reasons why SubVersion is really fast even with very big repositories.
I know what I'm talking about, the repository I maintain is now 2.8GB in size
What I'm really looking forward to is when SubVersion supports SQL based databases like PostgreSQL or SAP DB. That will be a killer feature, but don't hold your breath, the SubVersion folks say it'll take a significant amount of work to do this but they want to implement this eventually.
This has been discussed quite recently on the Subversion users mailing list, someone wanted to use Jalopy to format Java code on every commit. The answer basically is: nonononono, bad idea.
Check the mailing list archives, the initial posting was on February 12.
A company I work for has a few hundred developers using Perforce. At home I've been using svn for a few months. Here's my quick comparison:
Perforce:
Pros:
- Very fast. Very, Very, Very fast.
- Stable
- Decent cross platform support
Cons:
- Commercial (but not as expensive as BK)
- Binary-only--we can't (easily) fix it.
- Windows UI is a bit inconsistent
- Requires manual checkout
- Requires server for revert, diff, etc
- Stores client state on server. Thus there are coherency issues--if you 'rm' a subtree on the client, the server still thinks the client has it, and 'p4 sync' will not refretch it. It took developers a while to grasp the need for 'p4 sync -f' in this situation.
Subversion:
Pros:
- OSS License
- More features than CVS (already covered)
- Automatic file open (you can just start editing a file in a checked out module)
- 'svn status'
- Serverless revert, diff.
- Short learning curve
- Active developer/user community
Cons:
- Berkeley DB. Data does not seem to be very portable between different library versions. Yes, you can dump and reload, but the lack of binary compatibility is lame.
- SVN Schema Changes. These also require manually dumping and reloading the repository. SVN developers claim schema changes will be rare as of 1.0. I've been through three so far... we'll see.
- Berkeley DB. 50k in text takes 2-3MB in the DB. "Fortunately" there are arcane manual tools to prune it.
- Performance. Not slow, but local svn is slower than LAN Perforce.
- Berkeley DB. Twice I had to run db_recover when svn 0.36.0 locked up and/or refused to run. Tangential evidence suggests DB 4.2 fixed the bugs. Make frequent gzip'd backups of 'svnadmin dump' and you should be OK. Also test rigorously before you deploy--this is a 1.0, after all.
The work environment you're descriping is more typical of a small project or an in-house effort, not a broad distributed project. Think about needing to maintain released versions, to handle patchs and bug reports against that version, and to backport fixes to the current tree against that version.
Also, I don't know what language you primarly use, but as a C++ developer I don't remember the time I checked in just 1 file, unless I'm chugging through one-liner bugfixes. Changesets make sure that .h/.cpp (as a trivial example) commits are atomic, and have the aditional advantage of being much more efficent to update on the client.
It is a pain to set up and configure, but I agree with the grandparent that as a developer USING it, ClearCase is really nice.
I seem to recall that several years back (2001) sourceforge did some tests for subversion where they imported all of their repositories into a subversion repository as a stress test. (Yes, subversion has been working as a minimally functional VCS since then ... since then they've been adding features, refining protocols, and most importantly making it more robust.) I'm pretty certain sourceforge will want to be moving to subversion, or at least making it an option.
Secession is the right of all sentient beings.
There's also a (somewhat unrelated) project of the same ilk for CVS called, unsurprisingly, TortoiseCVS (different developers IIRC, same idea though, hence the similar name).
Somewhat unrelated? TortoiseSVN is a straight mod of the TortoiseCVS codebase made to work with Subversion. Yes it's different developers, but the TortoiseSVN guys got a giant head start on TortoiseSVN by using the code from TortoiseCVS. It's mentioned on both sites. I use them both, they are amazing tools.
Yes. There are a few reasons I can think of to do it:
You can also mix n' match those reasons. Or even extend them (esp the last one, think very very large open source projects with thousands of authors).
It's trying to use an install directly from IE using an tag, and even though you can download the individual cab files separately for install, it doesn't give you any alternative links for it (yay Microsoft). When I let Opera identify as MSIE 6.0 I can see the javascript flyout menus to take me to the download page. You can get to the "Full Download with Local Install" page here, but you still may not be able to see the links as they are created through some mangled javascript, so here they are:
PSDK-FULL.1.cab
PSDK-FULL.2.cab
PSDK-FULL.3.cab
PSDK-FULL.4.cab
PSDK-FULL.5.cab
PSDK-FULL.6.cab
PSDK-FULL.7.cab
PSDK-FULL.8.cab
PSDK-FULL.9.cab
PSDK-FULL.10.cab
PSDK-FULL.11.cab
PSDK-FULL.12.cab
PSDK-FULL.13.cab
BAT File for Extraction
Extraction Utility File