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.
I think this can be used with WebDAV to provide the missing versioning functionality as well.
Consensus is good, but informed dictatorship is better
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 Subversion successfully for about a month (http://svn.pdtp.org). Unlike CVS, Subversion is actually sane. You can *gasp* delete directories from the repository! You can rename/move files within the repository without losing versioning (possible but highly cumbersome in CVS). Branching makes sense. It still lacks some of the features of Perforce/BitKeeper but overall quite nice.
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.
One if you want to access SVN over a network. You don't need Apache if the repository is local.
-rick
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...
No, you dont have it straight. There is an apache module if you require web access, but it is optional. You can use subverion stand alone, using a directory on the filesystem as a repository, like cvs.
Hardly an unbiased evaluation.
The problem I have with these systems is, that as far I know, you have to check out files, work on them and commit them back to the revision system.
This is fine for most types of code, but for web development you really do not want to maintain a different local webserver for each developer, so my question is this:
Is it possible to work several people on the same files and still have version control?
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
You're kidding, right? One of the most annoying things about ClearCase is that it requires a kernel-mode driver to run (and that also makes it a bitch to get up and running).
That said, Subversion uses a database, not a filesystem, for its underlying device -- although the database is structured like a filesystem. Also when you check out files, you just check them out as normal directories on your local file system.
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
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).
If you mean do they "eat their own dogfood?", then yes. Subversion has hosted itself for quite some time now.
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.
No, it doesn't require apache. In fact, it's far easier to install if you don't use apache--it has a standalone server which is quite easy to compile and set up. I wouldn't recommend using the apache interface unless you have some reason to want other features of apache. The standalone server supports a primitive form of authentication, but more importantly, you use ssh for authentication and communication. This is trivial to set up and works great.
I've been using it for several months now, for several projects and also all my dot files in my home directory. Big improvement over CVS. Thanks, subversion developers!
This page compares SCM to each other. Very nice. But as always before reading comparisons, take a grain of salt.
s on .html
http://better-scm.berlios.de/comparison/compari
Actually, Windows does support softlinks, which are termed as junctions. See http://www.sysinternals.com/ntw2k/source/misc.shtm l#junction for more information.
oh oh, there are automated tools included. cvs2svn
Will convert your repositories. You should be able to keep the cvs as a backup or the subversion as a pilot.
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?
I have to look through it, but based on the way it works, it probably has two more benefits:
* Easier to set up and maintain user accounts (CVS requires setting up shell accounts)
* More secure. One can spoof history with CVS, corrupt the thing, or whatnot.
I'd like to see Sourceforge move to SVN, and see what happens...
May we never see th
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.
cvs does not (no longer) use rcs as a back end. It used to be a collection of scripts on top of RCS, but it's had it's own back end for a while now.
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.
Using svn through apache can obviously use ssl based http connections if you want.
You can also use Subversion without Apache, using ssh, which more or less works exactly the same way CVS runs over ssh.
Hmmm...
In Nautilus, right click a file or folder and click "Make Link". "ls -l" confirms it: regular symbolic link.
Now, maybe you're confusing what Gnome refers to ask "Launchers" (not sure what KDE calls it) with trying to be links. Launchers are not links, and will not be replaced by links. Launchers are meant for, yes, "launching" a command. They need to be a file since the file needs to store infomation on the icon to use, some comment information, etc. A link has none of this information, so it's not a suitable replacement.
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...
Any Apache authentication module will do... Also, because it isn't filesystem-backed, there is no need to have one system account per SVN account.
A nice *nix server running an Svn or CVS server can support a medium sized team of developers just fine. How the heck are you supposed to do this using Arch?
I'm really not sure what you're asking. Arch doesn't really need much in the way of hosting, so you could easily have your CVS serving machine host Arch archives as well.
Oh, you mean it really is designed to work primarily, if not only, with Unix-like operating systems?
One of Arch's assumptions is, indeed, a POSIX filesystem; basically every operating supports this, though. Unix-based systems natively, and Windows using Cygwin libraries or compiling with mingw. Actually, Arch users have encouraged the Cygwin team to shake out some bugs in Cygwin's long file handling support, so first-class Win32/Cygwin Arch really isn't that far off. Some of Arch's features (like revision libraries) take advantage of hard links if they're there, so some things may end up taking more disk space on Windows than Unix, but everything works fine.
Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
Yep! Arch's design is primarily as a distributed SCM; there's nothing keeping you from only using the one centralized archive in a centralized development model, though; you just have everyone use one branch. It really can be used just like CVS in that respect if you want to, just the command syntax is slightly different. Hell, I'm developing software in a centralized archive using Arch right now, though I'm the only developer contributing code.
Why do you say Arch is "outright useless for cross-platform" projects? I'm curious to hear what you have to say.
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.
I only meant more extensible than without. Or, for example, compared to CVS. I'm not familiar with Arch, although I am a little bit now and I'm sure it's a fine VCS. Having it as a server module does allow you to do things that you can't do with WebDAV alone. *Somewhat* like the difference between, say, perl CGI and mod_perl.
I don't want to sell anything, buy anything, or process anything. I don't want to sell anything bought or processed...
Because, in the words of the Subversion team, the CVS code is crufy, unmaintainable, and was long overdue for an overhaul.
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
There is an Explorer extension for Windows, which might be somewhat akin to filesystem support. I don't think you'd need quite as much filesystem support for Subversion, because it handles all the tags and branching in filesystem terms -- a branch or tag is just a copy of the tree (literally copied to another location in the repository), so it's naturally exposed as a filesystem-like interface (unlike, say, CVS, where the branch is a separate concept from the filesystem layout).
Copies and deletes still require tool support, but that can be solved in the UI (e.g., Explorer, Konqueror, Nautilus), instead of at the kernel level.
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!
yes, there are no serious bugs and there haven't been for months
There seemed to be several helpful replies to this, but I didn't see anyone linking you to the book, so there. It's good.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
- 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.
I have my Subversion server configured with a "svn" user, and a group for every project. Each user belongs to the appropriate groups. The authorizedkeys files have the user keys and a command to automatically run svnserve.
The repository directories and files are owned by user "svn" and the appropriate group. The setgid bit on the directories are set so that when Berkeley db4 creates additional log files, they end up owned by the correct group.
"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.
These are "post 1.0" issues. That is, stuff that has priority for the next release. It's kinda weird the list doesn't show that more clearly, but now you know....
KDevelop supports Subversion natively along with CVS, Perforce, and ClearCase.
Annoyingly, Mac OS aliases and Mac OS symlinks are not the same!
A symlink points to a specific path. If you move the file at the symlink's target, and replace it with a second file, the symlink now points to the second file, even on Mac OS X.
An alias points to a specific file. If you move an alias's target and put another file there, the alias still points to the old file. (With a bit of hacking, you can create an alias that works just like a symlink, but you have to write code to do it.)
The "ln -s" command creates symlinks, not aliases. As far as I know, there is no way to create aliases from the command line (other than using osascript and asking the Finder to do it for you). Even more delightful, aliases don't work for everybody. More than once, I have run into a situation where replacing a file with an alias to that file will break the program, because it reads the alias instead of following it. Using a symlink works fine.
Mac OS X also supports hard links. Except it doesn't. HFS+ doesn't support what you need for true hardlinks, so OS X fakes it with some hidden directories and something that looks like a hard link to the user but a symlink to the kernel. Or something like that.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
I just started using SVN on a large source tree - >1 Gigabyte, including many binary files. I'm using Windows, and found that CVS trashed all the binary files due to the stupid MS line ending issues. Subversion handles binary files perfectly.
This is a new repository - I didn't test the scripts for converting from CVS.
Subversion isn't as fast as I expected, given all the uninformed statements about "svn update" only having to check revision numbers. It looks like it does recurse into all directories, so performance is similar to CVS.
TortoiseSVN, the Windows front-end, was far too slow to be usable. I've contributed some patches to help with a couple of obvious problems, but don't have the tools to optimise it properly.
"Arch: a Monolithic Unix program. Attempts to port and to add tools are still ongoing."
Monolithic? It's based on standard tools like diff and tar, and contrary to what you say, Arch is more like a standard than a program. There are multiple implementations - larch (the fully functional prototype), tla (Tom Lord's arch, in C), ArX (by Walter Landry, in c++ I believe) and several smaller ones.
"Arch seems not only less useful but also depressingly backward-looking in philosophy."
Arch is conservative in some regards, but it's conceptually closer to bitkeeper, ClearCase and other modern version control systems.
xkcd is not in the sudoers file. This incident will be reported.
from some online CVS documentation :
It is possible to "map" cvs-specific usernames onto system usernames (i.e., onto system login names) in the `$CVSROOT/CVSROOT/passwd' file by appending a colon and the system username after the password. For example:
Thus, someone remotely accessing the repository on `chainsaw.yard.com' with the following command:
would end up running the server under the system identity kfogel, assuming successful authentication. However, the remote user would not necessarily need to know kfogel's system password, as the `$CVSROOT/CVSROOT/passwd' file might contain a different password, used only for CVS. And as the example above indicates, it is permissible to map multiple cvs usernames onto a single system username.
while (!asleep()) sheep++
In the FreeBSD project, we have a significant amount of code which is shared between several similar projects (NetBSD, OpenBSD, DFBSD and others). Having shared files include version control tags from all sharing platforms life a lot easier for the people who merge changes back and forth between the systems.
Still, I don't speak for the FreeBSD project and while it is my opinion that the lack of user-defined keywords is significant, the need for a viable cvsup replacement is a much bigger problem. Whatever, the decision to change version control products is not mine to make. If the project does move to subversion, I imagine it would only happen after a long process of testing and evaluation and that process hasn't even started.
They were not impressed :) but that was primarily because the lack of cvsup-like tool and 3dparty support.
-- Sig down
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
Windows Services For Unix 3.5 is now a free download. It includes GNU build tools (gcc etc.) and has pretty good POSIX support. You might give that a try.
Modifying files on checkout/checkin is incompatible with some of Arch's most interesting (and very effective) performance and space optimiziations, some of which are available in no other source control system existing. Creating working directories as hardlink trees out of the revision library is suddenly impossible; checking inode signatures to determine quickly which files changed becomes more complex; and these tags simply don't do anything useful that Arch's patchlog approach can't or won't.
Strong enough reason?
BDB doesn't have a "windows of corruption", it is a log baised relational datastore (some would say database, but I like to use a diffrent term to remind myself that BDB doesn't internally deal with any relations). Before the on-disk tables are written whatever is about to be overwritten is appended to the log file and sync'ed. Then the changes are made. If power is lost or the BDB process is killed the log files can be used to undo the half-completed changes. (this all assumes you dont ask BDB to not do it - which you can if you value speed over durability)
A BDB "database" can be corrupted, but it has to be done by hardware failure, or writing directly to the DB files, not merely by losing power at the wrong time.
I have used BDB in a number of projects (none of them storing source code), and not had a problem with corruption (except for the "throwaway" "tables" which I specifically chose to not have full durability protections on as I could recreate them from other "tables").