Slashdot Mirror
Subversion 1.1 Released
crafterm writes "Subversion 1.1 has just been released with many new features, including performance speedups, a new file based repository format, localized messages, and more.
Release notes are available http://subversion.tigris.org/svn_1.1_releasenotes. html"
There's a free online version of O'Reilly's Version Control with SubVersion
Sorry, the previous link is wrong, you should use this one instead: http://subversion.tigris.org/propaganda.html Look under "Testimonials"
The apache webserver is switching to subversion. This was said in the mailing list post here and if you follow the thread it gives some good reasons behind using subversion. Examples from the original proposal include mod_dav_svn and mod_authz_svn which are Apache modules for web interface to the source repository.
Other examples include The Commons TLP and the SpamAssassin project which are projects of the Apache foundation are already using subversion. To see all the projects Apache foundation projects using SubVersion just go here
Useful links: Subversion homepage
Version Control with Subversion Book (mirror)
Push harder towards Open Media/Content
Can you enlighten the group with your reasons why?
Hmm, let's see:
- No more vendor branch initial import silliness
- Even easier, faster branching
- Can point someone directly to a specific branch via URL
- Built-in repository browsing (via http)
- No lockfile headaches
- In general: faster, cleaner, more polished, slightly more streamlined workflow.
Random and weird software I've written.
In that case, do check out the svk project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.
One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.
I am implementing a darcs-compatible command set and patch tracking algorithm for svk, which should be merged to the main trunk on 0.23 or 0.24,
Also, svk interoperates with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.
I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.
I have worked extensively with CVS in the past, but my current project has adopted Subversion. Subversion corrects several deficiencies in CVS while retaining a very similar command syntax.
Improvements include:
- Atomic commits
- Historically trackable file/directory renames, moves, and deletes
- Simplified branching and tagging
- Less network traffic between client and server
- Better binary handling
The big missing component at this time is robust merge tracking. You have to do a little manual work during complex merges from long-lived branches, but that should be addressed in 1.2 or 1.3.
- Subversion keeps a local "pristine" copy of your current version. This means that many operations don't require an accessible repository.
- Subversion actually deletes files (and moves) when you ask it to, rather than the two-step operation required with CVS.
- Subverison makes atomic commits -- if one part fails, it all fails.
- Subversion sends diffs to the server, not the entire bloody tree.
- Branches and tags are very simple and constant time -- they're kept not as complete trees but as diffs of their predecessors.
There are other reasons, to be sure, but these are what I like the most.This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
For example, if I want to import changes between revisions 123 and 124 from trunk to current branch, I can just use svn merge url://path/to/repo/trunk -r123:124 and all changes in the trunk between those revisions will be merged in the current branch. Note that a revision is always the result of a commit and might include changes to a bunch of files and directories. And if something has been renamed in that commit, that change will be included too! If it later comes out (possibly after 10 more commits to the very same files) that such a merge was mistake, I can remove that merge just as easily with svn merge url://path/to/repo/trunk -r124:123. Note that I just reversed the repository numbers, so svn applies changes in reverse.
There're some things I don't like, though:
Just give the cvs2svn a try and play with svn with some real world sources. And keep the CVS repository running until you're comfortable with svn. Then use cvs2svn to do the conversion.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
One of the bigger changes that users of 1.0.x will see when upgrading is Greg Hudson's awesome new FSFS filesystem.
Subversion uses a db-like transactional filesystem to store your files, up until v1.1, Subversion used Berkeley DB to implement this filesystem. But BDB was somewhat of a headache for many Subversion users. Some issues:
With FSFS this problem is gone.
This never happens with FSFS.
Of course there are a ton of other nice fixes and improvements to 1.1, but FSFS shines above the rest. Also, there are rumors that FSFS will soon become the default filesystem in Subversion, I for one will welcome that change.
For more information about FSFS, Greg Hudson's original FSFS document is required reading.
I'm sorry if this post comes off as Berkeley DB bashing, I really didn't intend for it to be like that. To be fair, I think that Subversion put DB to use in ways that perhaps it was not intended to, and coupled with the fact that Berkeley DB is mostly a commercial product, I can sort of see why an opensource project like Subversion would take backseat to Sleepycat's paying customers. (I should probably mention that Sleepycat recently placed one of their employees as a "Subversion liaison" to help resolve BDB bugs/issues quicker.)
Thomas
I like Subversion just fine as a "better CVS" but if you're looking for a better version control system altogether, I would look into distributed version control systems like arch, or if you're looking for something with a better learning curve, darcs is really cool, and is implemented in the glorious Haskell programming language.
Distributed systems like these have a lot of advantages over the CVS/SVN model.
It is a very big deal if you've used Subversion for any appreciable amount of time. See my other post in this thread for a more detailed overview of BDB vs. FSFS. Or just take a look at the Greg Hudson FSFS document.
There is the little note; "Note that the data files created by fsfs repositories are still in a binary format, and are not human editable!"
Which brings up the question, why do you want your repositories to be human editable? With CVS, you needed it because CVS regularly screwed up your repository, with Subversion, that's guaranteed not to happen.
Also, when you use apps that use Berkeley DB, PostgreSQL, MySQL, Oracle, MS SQL, Sybase, or DB2 as a backend, does it bother you that your data is not human editable? Why should you worry so much about Subversion then?
And can it do hot backup, with guaranteed atomicity?
Yes, "svnadmin hotcopy" works just fine.
Thomas
I fail to see how this is a Subversion problem. The developers (almost none of whom get paid to work on the project) shouldn't be required to compile binaries for every operating system out there. That should be the job of your OS's package maintainer.
I think you're abusing the word "unstable" here. Subversion may use the latest and greatest versions of some libraries, but I don't think any are in alpha or beta status. (Could you point out any that are?)
Now, if you are having problems with your dependencies not being up to date, take that up with your package maintainer, whoever that may be.
False.
Subversion most certainly allows you to configure permissions on a per-user basis. It even goes so far as to allow you to fine-tune those permissions on a directory level (i.e. /src/foo is read-writeable while /src/bar is only readable and /src/quux is off-limits).
Don't place the blame for your failure to thoroughly read the documentation on Subversion.
This issue has been beaten to death several times on the mailing lists. Please read the archives.
And who said you have to upgrade your webserver to run Subversion? You can run Apache 1 and 2 just fine on the same machine, just use a different port for Apache 2.
Overall, I'm not very impressed with your inability to read documentation before you make uneducated statements like "People told me that svn supported various things, and convinced me to make the upgrade; they were largely incorrect, and this "CVS replacement" doesn't really deserve to be at 1.0, let alone 1.1."
Subversion, like any other tool, requires a bit of effort to switch over to. But the Subversion devs are smart people who have dealt with (and solved) all of the issues that you brought up. It is not perfect, but it is being actively developed and baseless complaining doesn't help anyone. In future, I advise you to read the docs completely, and ask the proper questions in the proper channels before you begin to criticize.
Don't get me wrong, Subversion has its share of problems. Some of these can be fixed, others require significant design overhauls before they can be addressed. But unfounded claims such as yours shouldn't need to be addressed several times per week just because you can't be bothered to look into them properly.
Thomas
I wrote about it here a few months ago http://www.gamesfromwithin.com/articles/0407/00002 6.html.
Fortunately, both those features are coming up soon by looking at Subversion's roadmap http://subversion.tigris.org/roadmap.html