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.
According to the download page, binaries may take a few days to appear.
What's so good about a version control system that takes days for binaries to appear? That's a pretty big bug to work out. (fp)
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.
Is sourceforge gonna offer this service in their project hosting instead of CVS now? Or will they allow both?
Cheers,
RoadkillBunny
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".
What a strange statement. Do you use XFree86? OpenSSH? There's any amount of such software out there under similar licences, and if the original BSD TCP/IP stack hadn't been under such a licence, it's doubtful the internet would be as interoperable as it is today, and if X hadn't been under the MIT licence, we'd be stuck with a bunch of incompatible proprietary windowing systems.
try this.
:)
Note: written by a subversion dev
Is there a filesystem that uses subversion as it's underlying "device"? For linux?
Some time ago I worked with Rational ClearCase and the filesystem integration was really nice.
Here's a comparison with 10 popular replacements
n .html
http://better-scm.berlios.de/comparison/compariso
Some time ago Doug Rabson posted a wishlist of features that would be needed to move FreeBSD to subversion (from CVS). Any idea on progress on these features? The site seems to be slashdotted.
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.
SourceForge said in a FAQ (IIRC of course) that they are waiting until a production version of SVN comes out. Now, when will they implement it? I'm waiting pretty anxiously.
The New Breed of Version Control Systems
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.
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.
Do not mod up people who point out cut-and-paste trolls logged in.
Many of these are folks who post plagarized articles and then point it out with another account to gain karma.
Do not mod up ACs who point out that people who point out people who post plagiarized articles.
Many of these are folks who are stuck in a bizarre recursive process of accusation and counter accusation against
folks who are stuck in a bizarre recursive process of accusation and counter accusation against
folks who are stuck in a bizarre recursive process of accusation and counter accusation against
folks who are stuck in a bizarre recursive process of accusation and counter accusation against
Oh, wheels-within-wheel-within -- oh just take the blue pill!
Opinions on the Twiddler2 hand-held keyboard?
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.)
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).
And yes, I know that some of you think this is a terrible, horrible idea and that my keyboard should be confiscated for even suggesting it. But this ability is on my "holy grail" list for version control systems, and I won't rest till I find it!
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've been following subversion for 2 years and waiting for it to be ready.
Last build we tried was a couple of months ago.
Try compiling it on different architectures (ours are i686-linux and hppa2.0-hpux11.00), mixing slight version differences, mixing which server you use (svn, http).
Then say hello to _constant_ intervention by someone who has admin privileges to recover your hosed repository.
I hate to say it, but now of course with 1.0 we'll try again. But I wouldn've thought they were a long way off based on our problems.
And this is with just 3 people using it on a test project? CVS has bugged me for years, but it can handle the basics without error.
I'm willing to admit that something we did could've caused all our problems (funny compiler flag or version, wrong switch enabled), but I can't afford the time spent trying to get a superior, but buggy, tool to just do the basics, even if the root cause is in some arcane step in the build process (which is truly hideous).
I wish them luck, but honestly I've never been able to figure out how all these happy subversion users ever got it to work.
There's still time though to pull the plug on our imminent order of Bitkeeper if by some miracle things have improved a lot very quickly.
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.
$1000 for one seat? What version are you getting and where are you buying it?
Microsoft Visual C++ Professional Edition, which seems to be the cheapest version with an optimizer in the Microsoft price list.
You can get Visual C++, which is all you need to compile most open source stuff, for $100 so
The version of MSVC available to the general public "for $100 or so" is Microsoft Visual C++ Standard Edition, which contains no optimizer. I've read that the performance of its generated code is so poor that one might as well use an interpreted language instead of MSVC Standard for new apps or run the UNIX version of an existing app in the Cygwin API translation layer rather than try to compile the Windows version in MSVC Standard.
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.
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!
We replaced 2 huge SourceSafe and 8-10 enourmous CVS repositories with Subversion.
We kept dual copies for about two weeks before feeling concident (only two projects was actully active, but with > 140 developers).
This was in the 0.27 version and haven't had a single glitch!!! And 1.0 is even better, of course.
My only complaint is not supporting locking, but this is obvisouly on the way. Nice for stuff like Word documents and UML files.
GO SUBVERSION!!! Also try TortoiseSVN... it's the best client and integerates nicely with the explorer. If you use Linux, there are lots of options too.
I'm glad to know an informed statement like "Arch is crap" and limiting its user base to "3 brain dead people" can get moderated to +1 so easily at Slashdot.
First, to address your claim on GNU Arch's quality, I'd like to point out that it's not meant as a correctional to CVS like SVN is -- the best description I've heard of it is as a formalization and automation of the development process that the GNU project used before Cygnus introduced networked CVS as an easier but more limited method.
One of Subversion's most important features in my mind is that of whole source patches (I think they may call them atomic patches or something). Good job SVN team (this is in all seriousness; I'd be foolish to wish harm on any F/OSS project). However, they've fallen down in the much more critical area: providing distributed development.
If CVS and SVN are the Cathedral, Arch is the Bazaar. When SCO posted their "Reasons to use SCO UNIX" list, one of the items was (paraphrased) "A single vendor" which most people criticized as being "a single point of failure" and I fail to see the difference in using a CVS or SVN archive. Witness the damage caused by Savannah getting compromised -- what if the same had happened to Sourceforge? (Arch has added GPG signed archives to address this issue.)
The freedoms held so dearly by the GNU project and the FSF are our freedom to make changes, but with centralized development tools like CVS and SVN, third party developers are second class citizens at best forced to get permission from the maintainers to make any changes -- patches must either be submitted via email or the client must ask permission to get added to the permissions list.
I don't like that.
And I'm sure many other people don't -- how many projects in our history have been forked because people had too much difficulty getting their patches into version control? Would OpenBSD have forked if Theo de Raadt could have still submitted his patches to NetBSD? Would EGCS have forked if the GCC steering committee could have gotten their patches in? Would Keith have forked X? Would XEmacs have forked FSF Emacs? The list goes on...
People don't like being treated like shit, and if you're going to treat them that way, expect them to do the same to you. Hackers are just like any other artisan -- they're proud of their work and if you treat it poorly, they consider it an insult to them. You don't necessarily need to accept someone else's patches into your own code, but you still need to respect their right to have their patches treated just the same as yours are treated (just think Voltaire as a modern day hacker: "I may not agree with what you code, but I defend to death your right to code it.")
As for the user base, aside from being self hosting, projects that are maintained using Arch include Rhythmbox, Squid, Xouvert, Y Windows (or so I'm told), and a few others (at least some other GNOME projects IIRC). GNU Emacs has added arch-tag lines to the source code to facilitate a change in the future, and the Linux source code is mirrored under Arch (a change from Linus to arch is pending *at least* some speed increases on large source trees and probably some more support/documentation).
I'd tell you to read some background on projects before making your stupid claims, but this is Slashdot so I don't know what the point is. Readers, please mod down the parent.
-jivera
- 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.
Before we migrated to Subversion we were using CVS. In choosing a replacement for CVSs' limitations we first evaluated arch.
In our opinion arch is junk. It works only on UNIX like systems (we have lots of systems that are not UNIX-like here, and we do use Win32 for some stuff).
Converting CVS with history looked to be impossible and we found arch very annoying to use.
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.
ClearCase wasn't cross-platform enough and was really more expensive than we could afford and MetaCVS seemed sluggish.
As a matter of personal opinion (mod me down if you want); we felt that (in the lab) arch felt like a toy and Subversion felt like a polished product.
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.
Many of the core Subversion developers are former CVS hackers. If they say the code they worked on for years is unmaintainable I believe them. CVS had fundamental (and obvious) architectural issues which you cannot solve by adding a bugfix here and a new feature there. Sure, it took a few years to make svn just do everything CVS already does, but did it harm anyone? From now on there is a much cleaner codebase which is easier to extend with new features, has less surprising corner cases for users, and makes it easier for new developers to start hacking it.
Although I am still undecided whether svn or arch will replace CVS for me (arch is nice, but its non-portability sucks, and whoever came up with the idea that using all kinds of funky hard-to-type script-unfriendly characters in filenames would make a vc system better in any way should be taken out and shot), I completely support the decision of the svn team to start from scratch.
Programming can be fun again. Film at 11.