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.

No more BerkeleyDB!

[StupidEngineer]

Woo hoo. 1.1 allows us to create repositories in the flat filesystem. Sorry, I'm not a big fan of BerkeleyDB.

But what I'd really prefer is if they moved the SQL RDBM backing feature up as a nearterm goal (roadmap say longterm). :)

How does it compare to Arch?

[caseih]

I've considering selecting a new repository system in the near future. I need to support a web site, as well as programming projects. I read an article recently that quoted the creator of Arch as saying that Subversion sucked because it was designed wrong. Of course he neglected to give any evidence of this. For those that have used both, which ultimate was the better choice, if any?

What's with all the dependancies?

[rimu guy]

There are over 30 subversion related packages in the install, including updated to db4, apr, httpd and mod_ssl. Moreover, it seems that (at least the last install I tried) these other packages must be updated as a pre-requisite for installing svn.

I want to use svn+ssh. I don't need any of the apache/webdav integration. And having to move to a custom version of apache is going to be a show-stopper for a lot of people.

And does anyone know why vanilla berkely db is not good enough for svn?

svn developers: please release a client/server that can be installed without requiring updates to other packages (unless you need that specific, extra, functionality). Do this and you'll increase the svn adoption rate.

--
CVS & SVN Hosting

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

Nice new feature:

[captainclever]

svn blame --verbose show extra annotation information
Haha.. otherwise know as "Who the fuck broke this bit of code"? :)

Re:CVS-Subversion anyone?

[mr3038]

tags and branches are just copies, and copies are very cheap space-wise in SVN. It's really quite clean.

okay. But now I have numerical revision "names" and I'd want to give more meaningful names for commits/revisions, how do I do that? There's difference between knowing that difference from r123 to r124 is bug fix to bug number 42 and having r124 an alias called bug42fix. That way I could more easily merge that fix to another branch. But I guess it all comes down to svn not really supporting changesets. Perhaps I don't undestand how svn works?