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)
This story seems to have jumped the gun a few hours; the 1.0 tarballs don't seem to be available yet.
However, you can download the latest Subversion sources from its Bitkeeper repository... no, wait...
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
What is the matter with an Apache/BSD license? Why must it be GPL?
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
So when does it replace Bitkeeper for the kernel?
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".
I don't think I'm going to try this version. I think I'll wait until they get to Superversion 1.0. Or maybe Superversion Platinum/Pro++ 1.0.
Find free books.
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.
I've always hated that about CVS and Arch.
A revision control system should simply work in one UNIX account across all users - it's easier to administer and is much more secure.
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.
i assume the client libraries are apache/bsd licensed. if they were GPL, then SunOne/Forte, Visual Studio, C++ Builder, and other systems could not include plugins for Subversion. So, we'd be stuck with either propritary solutions like source safe and clear case, or stuck with CVS access via fork() as many applications do now.
If you're really annoyed, write tirgis and tell them GPL with LGPL client.
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
Thank you, Mr. Cut-and-Paste (7th comment down).
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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...
More secure to have a patchwork of internal user tracking built into the app instead of using the OS's user tracking?!?!? I don't think so, especially since you can use advanced permissions like ACL's to block access to subtrees despite what the version tracking system might think.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Can someone give me a quick overhaul of what CVS acutally is and does? I am just starting to move from Proprietary to Open Source for my developments, and wonder what exactly CVS is, in the Proprietary world, most people just use a WinServer/SMB to share code, how different is CVS? I know it is pretty hard, but I want to know the exact concept of it and how exactly it will help improve efficiency/etc. Once I am done migrating from prop/opensource, i will probably write a paper or article on it, it is a rough journey but once you are halfway there, you fell like you just took on the world and won.
Sig: I stole this sig.
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.
Does it check for SCO IP on each commit?
No article should remain without a [bad] SCO joke.
The New Breed of Version Control Systems
How are multiple repositories (even in CVS for that matter) handled? Anyone have any experience with either Subversion or CVS?
... try having a sysadmin that prefers debian and see how long you have to wait. Sigh. I do like subversion lots though! :)
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
Hardly an unbiased evaluation.
You're right - ask for your money back.
is anyone using this in a large professional setting? I've been tasked with rebuilding the CVS server at my gig, and I'm almost done, but how hard would it be to convert and existing CVS repository over? I will be testing the setup for a few weeks after install, so this may be a good time to try out Subversion. anyone with exp please share your thoughts. tia
CB
free ipod and free gmail!
Subversion (well mod_dav_svn) is built on a filesystem-over-http protocol, of course you can use it like a filesystem, on just about every platform, or from many applications, or through your web browser (to read it, anyway).
Are you saying GPL projects don't fork? For an early counterexample, see emacs/xemacs. Even with the linux kernel, every distribution now maintains its own version, and it's rather hard to drop a vanilla Linus kernel into Red Hat or SuSE or Mandrake and expect it to run the same. But forking wasn't the point. The point with the GPL is that commercial vendors would not have picked a windowing system based on it, because shipping it as part of their system would have meant GPL'ing every graphical program they wrote, thanks to the virality clause. Name a single counterexample of a GPL'd library shipped as part of a commercial OS.
...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.
Apparently Subversion 1.0 doesn't support "sharing", where the same file appears in more than one place in the source tree. That's a lack. Microsoft SourceSafe does that, and it helps avoid those annoying situations that result in long include paths.
there's already an eclipse plugin available.
I am NaN
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
I agree with you, but I think that some people can get angry when code under the bsd licence is used in a closed source project (case in point: OpenBSD in Windows Server 2003). If you are interested in the multitude of "officially" open-source licences, look at opensource.org/licences
MOUNT TAPE U1439 ON B3, NO RING
Problem here is that many open source projects for Microsoft Windows will compile only on Microsoft Visual Studio, which costs over 1,000 USD for one seat. Will the Windows version of Subversion compile cleanly on MinGW+MSYS? Or will I have to try to compile the UNIX version on Cygwin? I'd go look myself, but the site seems to be slashdotted, and even the Google Cache runs extremely slowly because Mozilla won't render anything until it has failed to fetch the CSS from the slashdotted site.
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.
it always worries my when open source software relies on closed-sources or standards.
Very little demand seems to exist for completely open-source PCs. I haven't seen many computer manufacturers ship their machines with LinuxBIOS or any other Free firmware. Therefore, on most computers, LILO and GRUB (the most common Linux bootloaders) rely on a proprietary BIOS. Even if you exclude BIOS from consideration, most Free programs running on a proprietary operating system rely on the proprietary system's runtime library (e.g. msvcrt.dll, Sun libc, etc).
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!
What about this comment of yours, which is a verbatim copy of part of this post to the debian-legal list? You got +5 for that one, congrats.
"I'll say it again for the logic-impaired." -- Larry Wall.
Yes, my team does this. We have a web and java based scheduler application.
Our source is maintained with subversion and we have teams that concurrently work on different layers (data provider, ui, business logic). We run the project on jetty currently, even with two ui frameworks (struts+velocity and tapestry).
We use maven to build the war file, and start the appserver (with a patch we wrote to support jetty). This works very well for our team of around 14 people.
How about a web interface to sudo for adding user accounts?
/dev/null, whatever. But still, my paranoia's inflamed. By giving them a user my system's at least recognizing their existence, and that makes me uncomfortable because I am uncertain my knowledge of UNIX is complete enough I've locked off all the possible manners in which they could take advantage of that.
You're suggesting I put up a web accessible chmod root script just so someone can run a version control system?
I can see that for some people's situations, using the unix account system would be very attractive. However, not everyones'. I, specifically, have been needing to set up a version control server of some sort. I will probably wind up doing so on a personal machine. It is concievable at some point I could give other persons access to this server. If so, I do not want anyone who has access to this CVS server to have any sort of other abilities on my system. Yes, yes, disable FTP, set shell to
From a security perspective, every moving part you add to a system is a chance for something to go wrong. A versioning system implementing its own internal security system adds a hell of a lot of moving parts, but they're all well contained off in userland, there's some vague notion of a sandbox there. A versioning system using the OS user system is adding a very small number of moving parts but those moving parts are in a much more dangerous area...
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Looks neat. Just checking:
Has anyone used this on Mac OS X / with xcode? I'm interested in doing so; if I want to, do I just sit down and follow the instructions or are there any gotchas or OS X-specific quirks I may run into that I might need to be aware of?
Thanks.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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.
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!
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
Linus wants a distributed system, which Bitkeeper is.
Did Linus evaluate GNU Arch? If so, what did he find wrong with it? One of the goals of Arch is to replace Bitkeeper. Yes, there exists one known feature that Arch lacks compared to BK, namely copying files within a repository while forking its change history, but why did Linus find this a showstopper? Or has Arch progressed rapidly since the BK decision?
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
Now I have little against PVCS (price tag being one thing, and some crappy network functionality that likely has been resolved by now).
If you mean how it takes something like 24 hours to upload a 2-3GB file (across a ~100MB/sec link to a remote server), then no, it hasn't been resolved.
PVCS has to be the most overrated piece of software ever. When I had to act as a liason between developers who were forced to use it and the PVCS administrators at work, I asked the PVCS admins to speak to the vendor about the insultingly slow performance. Their answer? That we should buy a cluster of Windows machines running Citrix that was local to the Unix database server which hosted PVCS and have all of the developers run the client from there instead of their desktops.
That was just the most laughable experience with their "support" team, since usually they wouldn't answer questions at all.
Buying PVCS is like buying an alarm clock that wakes you up by stabbing you in the eye with an icepick repeatedly. I'm sure it will do its job (sort of), but there are much better ways to get what you need.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
However, some other groups in my organization like alternatives like PVCS. Now I have little against PVCS (price tag being one thing, and some crappy network functionality that likely has been resolved by now).
PVCS does, however, lack a lot of CVS functionality, much less SVN functionality. I'm rather pleased to see another good reason to get rid of PVCS coming up.
May we never see th
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.
...it's meant as a general file versioning system. However, there are indeed various hooks so in theory you could set something like this up. Have a look at the subversion book (linked elsewhere in the comments).
I am NaN
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.
Is this likely to get Linus to switch from Bitkeeper? If not, what needs to be done to make it a suitable replacement?
Or am I wrong? Yes, I know VS is an unholy horror, but some of us are stuck with it for work. I use Jalindi igloo to interface with CVS, and would likely use subversion (heard nothing but good things about it) if I had 2 things:
1) the VS.NET source control plugin
2) a good way to "upgrade" an old CVS repository
I'm guessing #2 is supported, but #1?
As much as I'd love to see a Subversion filesystem driver in Linux, I am not sure if that would be possible. Would such a thing be legal under BitKeeper NDA to implement by Linux kernel developers?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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.
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.
What I'm going to do when I finally get things set up so that I'm not the only one using scm is set up staging areas as a virtual hosts on the same server as subversion. Every time there's a commit to a developer's branch, it's automatically exported to his staging area so he can test it. If everything works nicely, he can then merge into the global developer branch. Finally, when we're ready to do a full release, we merge the developer branch into the release branch, and it's automatically exported to the production server.
It's a little extra administrative overhead, but worth it for me to do the extra work, since I'm the only one on the team who's ever used scm, so I've got to make at easy for them as I can. Fortunately, for now, it's a small team, so I don't have _too_ much work to do to get it set up... and once I've got everything figured out completely, I can script adds, moves, and changes.
Granted, it would be great to finally see Subversion nicely integrated with SourceForge, but CVS (the current concurrent versioning system used by SourceForge) while lacking lots of essential (at least for experienced developers) functionality, is free software nonetheless. What I am most concerned about is whether this new version of Subversion is already good enough to use with Linux, so one could contribute without the need to choose between restrictive EULA and being a second class citizen. Does anyone know what features exactly does it still lack, if any, for Linus to accept? I hope it would be legally possible to accept now, but I might be wrong.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
So supposing I'm currently stuck having something like 50Mb of source code in CVS. Is there a migration tool to move it into SVN with all the versions maintained?
Karma: It's all a bunch of tree-huggin' hippy crap!
I can't be the only one that is unimpressed by Subversion.. and a little disappointed that this is the best the open source community can come up with.
When I first started reading about Subversion (a few YEARS ago), I was ready to be blown away. I thought it would be fast and powerful, yet light and minimal like CVS. And I expected features like distributed repositories and changeset management built in from the start.
But after using it for a while (and I have been using it for a couple major projects) and studying the design, I don't like it much.
One thing that's great: they stripped down the CVS interface, and removed all the confusing and conflicting commands and flags. svn now has a nice orthogonal command set, but still easy to use for a CVS old-timer.
But under the surface.. WOW a berkeley DB? Implementing a *versioned filesystem*? Talk about over-engineering!!
First of all, a versioned filesystem is not the right solution for version control. Version control is about *changesets*, not file snapshots. Subversion is concentrating on the nodes of the change graph, not the edges. Their solution is extremely "heavy". Changesets cannot be added to this model. It's possible to *generate* changesets from various snapshots of the tree (i.e., which sets of revision deltas make up a particular changeset), but that's also possible with CVS and a horrible hack.
A better solution would be designed around changeset management from step 1. And it wouldn't take X years to finish.
Second, the Berkeley DB is a key/value database. What the heck does that have to do with versioned trees?
Berkelely DB installations are difficult to back up, they can't be placed on network drives, they have locking issues, they create journals and logfiles and all kinds of junk. To back up our svn repositories, I'm just dumping the whole damn thing every night into a massive text file. Yeesh. (Actually it's not a text file, the binary files are dumped right along with the text, so it's actually a binary format).
Want another example of using berk DB where it shouldn't be used? The RPM package manager. A huge pain in the ass, but that's a rant for another day.
And yeah the WebDAV thing (which was installed by default when I installed svn from FreeBSD ports) sucks too. Maybe when I have some time I'll figure out the non-Apache dedicated server. But the WebDAV server should just be dropped completely, imo, it seems to just piss people off.
The Subversion folks should've been much more minimalist in their design. They should've aimed for the *simplest* design that could meet the requirements.
I've taken a look at Arch, and it has the opposite problem of subversion: damn nice internal design, but crappy interface (I recall the help text that listed commands was almost 200 lines long)!
Internally arch is great. It doesn't need any fancy database, all you need is a filesystem with atomic renames and other Unix-y features. It handles changesets, it handles distributed repositories, it handles "checkpointing" complete copies of the source code (so you don't have to spend a lot of time applying deltas to get to a specific revision)... it does it all once you figure it out.
The subversion folks should've taken Arch, cleaned up the interface, come up with some compatibility code for non-Unix platforms, and called it a day.
Ahh, but that would've been too easy.
Don't get me wrong, Arch is a very nice concept and it has some merits, but don't pretend there aren't advantages to Subversion's architecture. And the Subversion way of doing things is much more natural for a lot of existing professional software development teams. 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.
The BitKeeper model is so breath-takingly elegant. I used Sun's TeamWare (BitKeeper's predecessor) with great success, and am sorry to have to use Perforce in my current job.
The idea is that there are no branches. There are only repositories (each developer has one or more) and files. Each repository has full information of the version history, and there's no version control server.
Benefits of the BitKeeper model:
- Exchanging changes between developers without contaminating the common parent repository is safe and trivially easy.
- You check files in locally in your repository. So they don't even have to compile. It's often a good idea to check in files several times a day. Committing the changes to the parent repository is a separate operation.
- The repository is little more than a directory tree containing SCCS files. Should you want to liberate yourself from BitKeeper and go with a free competitor, chances are your SCCS tree can be accepted as-is by the new version control system.
- Since releases are managed as repositories (instead of branches), bug fixes can be propagated between releases as simply as within releases if there are no conflicts.
- Since there is no central server, transporting repositories, say, from hard disk to hard disk is as simple as copying the trees recursively.
$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.
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.
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:
That's like saying that for C code you don't want to keep the libraries installed on every developer's computer.
...which is obviously wrong. You do want to maintain a different local webserver for each developer. That's the whole point of revision control: more people can work on it at once. Not to mention, the website doesn't fall to pieces every time you make a typo.
How long does it take to set up a web server, anyway? "apt-get install apache php4" and you're done.
I do this for one-person development too: I hack on my desktop machine, and then "svn commit" and it gets committed to the repository and automatically checked out on my web server. (Look in [repos-path]/hooks of any SVN repository for how to do this, it's very easy and less of a hack than in CVS.)
Anyway, barely compiling for the last three weeks isn't exactly stable Windows support that I would feel comfortable rolling out into a corporate environment for professional software development work. Like I said before, Arch is a great concept, and I'd love to see more done with it, especially in terms of getting it to work out-of-the-box with Windows (i.e. I can roll it out to a development team with a single installer) so it was useful for cross-platform and Windows development. Until then, it's great for Open Source projects that themselves have a more distributed model of development which is nicely matched by Arch's capabilities.
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.
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.
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
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.
After fourteen months of coding, Subversion became "self-hosting" on August 31, 2001.
lame. Skynet became self-aware on August 29!
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.
KDevelop supports Subversion natively along with CVS, Perforce, and ClearCase.
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.
Richard is happy that Free Software (GPL'ed or not) is sold commercially, either by itself or embbeded in services, what he isn't happy about is for software that has its users submit to the author.
All software should be free as in freedom, so I completely fail to see the problem here. Popularity is a shallow goal, so you should aim for freedom for everyone, instead of popularity. If you respect your users and your software is good, popularity will likely come.
However, if popularity is your goal, you will likely start disregarding many good choices because they can be seen by some as not so popular...
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++
I think we need a new moderation category.
I know this is slightly off-topic, but I wonder if anyone is aware of an open-source Electronic Document Management System (EDMS). The specification for CVS/Source Control and a EDMS are very similar:
- Document profiles
- Full text indexing of all documents regardless of file type
- Combined searching of both profile and full-text index
- Integration with major software applications
- Individual document security and the ability to secure whole categories (e.g. financial information)
- Version control
- Audit trail to see who has (accessed / changed / checked-out / printed) documents
- Reporting on documents (all documents used by Joe Bloggs, all documents used within last 3 months)
- Check-in/Check-out of documents
- Local copies (Mirroring) so that you do not need a network connection (allowing laptop use)
- Web-access to all documents
I wonder if anyone knows of such a system?
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.
Sorry, that should be "ACLS still are not standard in the UNIX world".
Fedora Core 1 still, I think, does not use ACLs (by default). Most software doesn't understand ACLs. I've heard a lot of disparaging comments made on LKML about POSIX ACL design -- not sure how accurate it is, but it's there.
If I'm writing something, I can't just use ACLs and assume that they'll be there for the BSD, the Linux, the Solaris, the OS X users of my software.
May we never see th
You don't really know what you're talking about. Macintosh Aliases are not at the kernel/filesysten level (which implies that all the linkiness is taken care of for you by the library functions you call). Aliases were just data files (with file type 'alis') that the Finder (and most other applications) knew how to handle. Each program had to manually resolve aliases in the code (using one of the ResolveAlias functions). You could even open an alias file, read in the file data, and resolve the alias in memory. This allowed you to use aliases that are stored in a different manner to alias files (e.g. Mac OS shlb's allowed you to store an alias as a resource to a directory containing other dependent shlbs). Under Mac OS X aliases are still present and still (rightfully so) are not handled in the File System layer. You have to use Carbon API calls to access/resolve the alias and _more_ Cocoa/BSD code should be doing that.
I have trouble with passwords among other things.
Stop thinking like a UNIX programmer and start thinking like a non-technical person.
What are you talking about? CVS isn't meant for non-technical persons. Never has been. It was designed as a tool for UNIX programmers.