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"

Comments

SVK. :-)

[autrijus]

However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

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.

Re:CVS-Subversion anyone?

[lonenut]

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.

FSFS

[nthomas]

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:

• no networked filesystem - since BDB (along with many other databases) used file locking features that were not available over network shares, you couldn't host your Subversion project over NFS/AFS/CIFS(Samba).

  With FSFS this problem is gone.

• wedged repositories - for some people their Subversion filesystem would inexplicably "lock up", requiring the sysadmin to run "sdvnadmin recover" on the repo. It was actually BDB that locked up, and sdvnadmin recover actually ran the Berkeley DB recovery procedure on a repository, but most people blamed Subversion.

  This never happens with FSFS.

• smaller repositories - because it stores deltas, FSFS repositories are smaller than BDB ones. Greg Hudson's FSFS documents claims that "space savings are on the order of 10-20%", but that's a modest claim. I've personally seen myself (and others have mentioned) significantly smaller repos when switching over to 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

Re:distributed systems are more interesting

[DylanQuixote]

Or http://svk.elixus.org/, based on the SVN and implemented in Perl.

Still no optional lock and merge tracking

[llopis]

Optional locks and merge tracking are the two features that are holding Subversion back from being a real candidate for production code.

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