Subversion 1.0 Released 587
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.
What's with that? (Score:5, Funny)
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)
Bah, a few days... (Score:5, Funny)
Re:Bah, a few days... (Score:5, Informative)
Re:Bah, a few days... (Score:5, Informative)
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).
Re:What's with that? (Score:4, Funny)
Re:What's with that? (Score:5, Insightful)
Re:What's with that? (Score:5, Insightful)
All files are binary. What most people mean when they say "binary file" is "non-plaintext."
Re:What's with that? (Score:5, Insightful)
Will I need MSVC? (Score:5, Interesting)
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.
Re:Will I need MSVC? (Score:5, Informative)
Re:Will I need MSVC? (Score:4, Funny)
<tongue firmly in cheek>Instead of paying the $1000 for VS, buy an Itanium server. The VS compiler is free for IA64 (though it doesn't come with the IDE). It's included in the (free) MSDN download</tongue>
No optimizer in MSVC Standard Edition (Score:5, Insightful)
$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 [microsoft.com].
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 [microsoft.com]. I've read that the performance of its generated code is so poor that one might as well use an interpreted language [python.org] 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.
Where can I buy LinuxBIOS PCs? (Score:5, Interesting)
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).
Re:CVS and others (Score:5, Informative)
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.
Re:CVS and others (Score:5, Informative)
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.
Re:CVS and others (Score:4, Informative)
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...
Re:CVS and others (Score:5, Informative)
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.
Re:CVS and others (Score:4, Informative)
sf.net (Score:5, Interesting)
Re:sf.net (Score:4, Informative)
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.
Works well (Score:5, Informative)
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".
still waiting (Score:4, Funny)
Filesystem driver? (Score:5, Interesting)
Some time ago I worked with Rational ClearCase and the filesystem integration was really nice.
Re:Filesystem driver? (Score:4, Interesting)
It's a revision control system masquerading as an NFS filesystem/server. Pretty damn cool. It's 99% written in Perl.
Re:Filesystem driver? (Score:4, Informative)
Re:Filesystem driver? (Score:4, Funny)
Re:dude, WebDAV (Score:5, Informative)
- 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.
Re:Filesystem driver? (Score:5, Informative)
10 revision control system comparison (Score:5, Informative)
http://better-scm.berlios.de/comparison/compariso
Re:10 revision control system comparison (Score:5, Informative)
FreeBSD (Score:5, Interesting)
Re:FreeBSD (Score:5, Informative)
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.
Re:FreeBSD (Score:4, Interesting)
Out of curiosity, could you repeat some of the reasons for opposing this? In this particular case, it seems that it's viewed as a fairly significant stumbling block by a large and influential potential adopter (FreeBSD).
I've never worked in an environment where we specifically needed this capability, but my general experience is that it's a poor choice to sacrifice flexibility unless there's a strong technical reason for doing so.
Why Subversion Kicks Ass (Score:5, Informative)
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.
Re:Why Subversion Kicks Ass (Score:4, Interesting)
Bogus. GNU Arch [gnuarch.org] is based on a filesystem-based repository as well, but can revision file moves, permissions, symlinks, and so forth.
Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB. (Yes, call me paranoid -- but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times). The repository format is write-once, so the files in the repository, once created, are never overwritten or modified as new history is added (unlike CVS's
There are other reasons to prefer Arch as well, including distributed repository support, history-sensitive merge operators, and arguably superior core design.
Yes, I'm glad to look at SVN on its merits alone -- and while it's a huge improvement over CVS, I still find it lacking compared to the other modern revision control systems out there.
Re:Why Subversion Kicks Ass (Score:5, Insightful)
However, I've been using Subversion for quite a while, and it has never yet lost any of my data.
I have had occasional RPM database problems, but as far as I can tell they have been due to RPM problems, not due to Berkeley DB problems. In my experience Berkeley DB is fairly robust.In principle, there is no reason why Subversion can't use your favorite relational database as the back end. The Subversion developers chose Berkeley DB as the first back end implementation, but there may be others in the future.
That's rather vague. What's better about Arch's core design? (I'm not trying to knock Arch; I just don't know much about it.)+1 Civil (Score:5, Funny)
more information (Score:5, Informative)
Version Control with Subversion
Draft Revision 8770
Ben Collins-Sussman
Brian W. Fitzpatrick
C. Michael Pilato
-jim
Now will SourceForge adopt it? (Score:5, Interesting)
If you need a nice subversion client on windows... (Score:5, Informative)
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.
Re:If you need a nice subversion client on windows (Score:4, Informative)
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.
slashdot a bit over-eager (Score:5, Informative)
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).
Renaming yes, sharing no (Score:4, Insightful)
Re:Renaming yes, sharing no (Score:4, Informative)
Re:Symlinks under Windows? (Score:5, Informative)
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.
Re:Symlinks under Windows? (Score:4, Informative)
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.
Re:Renaming yes, sharing no (Score:4, Interesting)
Softlink (aka symlink): Has it's own file, but any access gets routed to the real file. This is what most links I deal with are. If you delete the real file, the link breaks, but stays there.
Hardlink: Doesn't have own file. Behaves exactly like the original in all ways, but has a different name. If you delete a hardlink or the original file, nothing happens until *all* instances are gone. Hardlinks must be on the same partition.
In Linux under ext2, hardlinks are files with the same inode number. I don't know exactly how softlinks work, but they have different inode numbers than the original.
Windows with NTFS supports hardlinks as mentioned in other posts, and softlinks as shortcuts.
So to sum up, the links you were referring to were hardlinks, and as such rightfully can't go across network. The pseudolinks you were talking about are simply shortcuts, and usually don't work in applications due to shoddy programming.
Re:Renaming yes, sharing no (Score:5, Informative)
FAQ (Score:5, Informative)
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
astyle, indent, etc. with subversion (Score:5, Interesting)
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!
Subversion not really a source-code repo... (Score:4, Interesting)
Re:astyle, indent, etc. with subversion (Score:4, Informative)
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.
Re:astyle, indent, etc. with subversion (Score:5, Informative)
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.
Re:astyle, indent, etc. with subversion (Score:5, Funny)
Anyone know if there is a way to use subversion for automatic canonization of code style?
Yeah, host a python [python.org] repository with it.
Don't suppose there's a Visual Studio plugin yet (Score:4, Insightful)
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?
Re:Don't suppose there's a Visual Studio plugin ye (Score:4, Informative)
VS.NET plugin. (project page, with downloads, normally here [tigris.org] but currently blown away by the load. Maybe grab it from the Google cache of the page [216.239.41.104] 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.
Major data corruption issues (Score:5, Interesting)
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.
Re:Major data corruption issues (Score:5, Informative)
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.
Don't jump the gun, folks! (Score:5, Informative)
Thanks for all the nice comments. Stay tuned for the official announcement.
completely underwhelmed by Subversion... (Score:4, Interesting)
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.
Re:completely underwhelmed by Subversion... (Score:5, Interesting)
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.
Re:completely underwhelmed by Subversion... (Score:4, Informative)
"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
Re:completely underwhelmed by Subversion... (Score:5, Interesting)
What you say about subversion may be true (it works okay for me but it could certainly do with a bit more power in places).
However, to say that arch is _better_ because it relies on Unix to the extent of being uncompilable on Windows (probably works in cygwin, but...) is bizarre. Arch suffers from the common GNU problem of assuming that a Unix system with a Unixy filesystem is the only environment worth paying attention to, and despite what Richard Stallman might think, that _is_ a problem.
Subversion: a cross-platform library for which many tools can be (and have been) made for many environments.
Arch: a Monolithic Unix program. Attempts to port and to add tools are still ongoing.
Arch seems not only less useful but also depressingly backward-looking in philosophy.
VERY easy to convert (Score:5, Informative)
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.
A couple of factual corrections. (Score:5, Informative)
Also, he was early
Anyway, it's almost Monday now, so check back soon at http://subversion.tigris.org/ [tigris.org].
Installation for BerkeleyDB, Apache, Subversion (Score:5, Informative)
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>
Re:Installation for BerkeleyDB, Apache, Subversion (Score:4, Informative)
make sure LD_LIBRARY_PATH includes /usr/local/BerkeleyDB.4.2
Gah! Don't use LD_LIBRARY_PATH [visi.com]. Instead you should be setting LD_RUN_PATH when you compile applications that will use the Berkeley DB library.
success story (Score:5, Interesting)
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.
Re:success story (Score:5, Informative)
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.
Comparison With Perforce (Score:5, Informative)
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.
Re:Not bad, but... (Score:5, Informative)
It's released under an Apache Style [tigris.org] license.
Google Cache [216.239.39.104] since the site seems to be dying as we speak.
Re:Not bad, but... (Score:5, Interesting)
Re:Not bad, but... (Score:5, Informative)
Re:Not bad, but... (Score:4, Informative)
Octopy [hp.com] looks like a promising qt gui frontend for arch to solve that problem.
Get your facts straight. (Score:5, Interesting)
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
Re:Not bad, but... (Score:5, Insightful)
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.
Re:Not bad, but... (Score:5, Informative)
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.
Re:Comparing the software (Score:5, Informative)
Re:Comparing the software (Score:5, Funny)
You're right - ask for your money back.
Re:Comparing the software (Score:5, Informative)
Note: written by a subversion dev
SVN Anti-FUD (Score:5, Informative)
Also, #svn channel on freenode irc is helpful.
Re:Comparing the software (Score:5, Informative)
Re:Does Subversion require a UNIX account per user (Score:5, Informative)
Supported write protocols include webdav, sftp (the one that's part of ssh) and ftp. Shell access is never required.
Re:Does Subversion require a UNIX account per user (Score:4, Insightful)
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...
Re:GREAT! (Score:4, Insightful)
Re:GREAT! (Score:5, Informative)
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).
Why not GNU Arch instead of Bitkeeper? (Score:5, Interesting)
Linus wants a distributed system, which Bitkeeper is.
Did Linus evaluate GNU Arch [gnu.org]? 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 [berlios.de], 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?
Re:Why not GNU Arch instead of Bitkeeper? (Score:4, Interesting)
The problem with SVN is that its just CVS with the most horrible problems removed and some other horrible things added (Apache/WebDAV).
Arch took a step back and really tried to come up with solution to an abstract problem. That makes it far better for revsion control than CVS and SVN.
Re:Why not GNU Arch instead of Bitkeeper? (Score:4, Informative)
Re:Mirror? (Score:5, Informative)
Re:It runs on top of Apache? (Score:5, Informative)
Re:It runs on top of Apache? (Score:5, Informative)
Re:with WebDAV as well (Score:5, Informative)
* 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...
Re:with WebDAV as well (Score:5, Informative)
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.)
Re:RCS can handle binary data since v5.7 (Score:5, Informative)
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
Check on tigris.org (Score:5, Informative)
Re:Check on tigris.org (Score:4, Informative)
Re:MOD DOWN - NEW TROLL ALERT (Score:5, Funny)
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!
Re:kernel (Score:4, Informative)
Re:This may be a dumb question (Score:5, Interesting)
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.