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

CVS-Subversion anyone?

[Dr. Bent]

Anyone out there move an existing project from CVS to subversion? Can you enlighten the group with your reasons why?

Thanks.

Re:CVS-Subversion anyone?

[ebash]

Take a look at the propaganda page on subversion's web site http://subversion.tigris.org/propaganda.html/

Re:CVS-Subversion anyone?

[ebash]

Sorry, the previous link is wrong, you should use this one instead: http://subversion.tigris.org/propaganda.html Look under "Testimonials"

Re:CVS-Subversion anyone?

[Cecil]

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.

Re:CVS-Subversion anyone?

[Anonymous Coward]

Well, I can tell you why I'm NOT:

CVS works fine for me and works on all my machines. The only problem is the UI of the cvs command line tool which is a little crusty (how exactly do you import an existing code base into CVS again?).

Also I DO NOT like the "do-it-yourself" branching/tagging of Subversion. I like to use lots of floating tags, before and after big changes, pre/post merge markers, etc., and doing it subversion's way is just weird. I can appreciate the thinking behind it (hey, it's just more versioned nodes on the tree, let's generalize), but I wish they would enforce a little more structure and create UI for it.

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.

Basically I want BitKeeper without the, uhm, asshole.

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.

Re:CVS-Subversion anyone?

[legLess]

My reasons:

• 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.

Re:CVS-Subversion anyone?

[mr3038]

I ported our inhouse CVS repository to subversion (svn) mainly because svn supports renaming and moving of files and especially directories. Later I've found that I'd rather take system based on 'changesets', but luckily svn can emulate those suprisingly well with it's -rN:M syntax.

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:

• CVS was faster in many simple cases like, for example, cvs commit. I've been told that SVN has much faster branching and other stuff that I never learned how to do with CVS. Branching is fast, I have to admit that.
• svn has no tags or branches (or it has both but those are "only" full copies of the "branch source" directories). I'd also want to give revisions symbolic names (this is how I understand "tagging") so that I could refer to special revisions by name instead of some random number.
• svn stores all data in a database. Fortunately 1.1 seems to fix this. If you have really many developers accessing the repository a database might be the best choice but for smaller projects it was a bit too complex system. Now svn can support both systems and you can start with fsfs-backend and later upgrade to real database if you really need it.
• If I don't remember to run svn update every now and then, I end up with "mixed working copy" which isn't always a good thing because "mixed working copy" has some serious limitations in the current implentation. You might end up needing to run svn update even when you don't want to do that.

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.

Re:CVS-Subversion anyone?

[AndyCampbell]

I run a website with a membership paradigm, where the members have access to the source code, but only select developers can commit changes. We recently switched from CVS to Subversion, and I must say that the process was rather painful. 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.

You can download a pre-compiled binary, but it was several builds behind and missing some vital features when we made the switch, and so we had to compile from source. There are numerous dependencies that are all in unstable status, we had to upgrade and recompile half the server platform just to get svn built.

CVS allowed per-user authentication, such that I could set up some users to be authenticated as read/write and others as read-only, for the cases when a non-committer needed an update of the code immediately without us having to go off and build a tarball and have them download it. Subversion does not support this, instead allowing "anonymous" and "authenticated" access levels - you're either logged in or not, and get read/write permission accordingly, with no ability to configure permissions on a per-user basis.

CVS allows you to use a standard htpasswd file for storing hashed passwords along with user names. Subversion requires the passwords to be in plain text mode, so I had to ask all my developers to generate random passwords so that I wouldn't be accidentally exposed to passwords they use for other things.

We can't use the web-svn server because it needs to run through Apache 2.0 and we're running 1.3 still, without the option to upgrade because of some other plugins that haven't been ported.

The server is a royal pain to set up, the cvs2svn script is ok but not stellar, the "subversion book" is useless as a setup guide but might be useful as a reference to the experienced SVN user, and the lack of web-svn is pretty poor too. TortoiseSVN is also still under heavy development, and has some annoying version-change conflicts.
On the bright side, the single-commit operations are considerably slicker.

Overall, I'm not very impressed with Subversion, and will probably still keep updated my CVS repository in parallel until SVN gets its act in order. I'll take a look and see if 1.1 fixes any of my complaints.

Re:CVS-Subversion anyone?

[DylanQuixote]

tags and branches are just copies, and copies are very cheap space-wise in SVN. It's really quite clean. Mainline development in /trunk, branches under /branch/ and tags in /tags/...

Re:CVS-Subversion anyone?

[ldspartan]

It seems like most of your problems stem from trying to do complex access controls without using Apache2. Run an apache2 instance on a loopback interface and forward to it with mod_proxy. Then you have all the nice, fancy ACLs and authentication of apache2 and mod_dav_svn without having to trust your entire site to Apache2. svnserve is not intended to be robust and fancy, it's best suited for when you absolutely cannot use Apache2 to provide repository access. mod_dav_svn works a lot better.

Also, complaining about having to compile your open source software? What the crap do you expect. Either use a distro with better package management (*cough*Debian*cough*) or pay someone with a clue to do the work for you. I'm available at $80/hour if you'd like.

--
lds

Re:CVS-Subversion anyone?

[nthomas]

You can download a pre-compiled binary, but it was several builds behind and missing some vital features when we made the switch, and so we had to compile from source.

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.

There are numerous dependencies that are all in unstable status, we had to upgrade and recompile half the server platform just to get svn built.

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.

CVS allowed per-user authentication, such that I could set up some users to be authenticated as read/write and others as read-only, for the cases when a non-committer needed an update of the code immediately without us having to go off and build a tarball and have them download it. Subversion does not support this, instead allowing "anonymous" and "authenticated" access levels - you're either logged in or not, and get read/write permission accordingly, with no ability to configure permissions on a per-user basis.

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.

CVS allows you to use a standard htpasswd file for storing hashed passwords along with user names. Subversion requires the passwords to be in plain text mode, so I had to ask all my developers to generate random passwords so that I wouldn't be accidentally exposed to passwords they use for other things.

This issue has been beaten to death several times on the mailing lists. Please read the archives.

We can't use the web-svn server because it needs to run through Apache 2.0 and we're running 1.3 still, without the option to upgrade because of some other plugins that haven't been ported.

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 Subversion, and will probably still keep updated my CVS repository in parallel until SVN gets its act in order. I'll take a look and see if 1.1 fixes any of my complaints.

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

Re:CVS-Subversion anyone?

[lphuberdeau]

If I remember well, Debian moved everything to subversion a while back. I don't think you will ever see a larger transition.

Re:CVS-Subversion anyone?

[nuba]

Lets see, the access methods are ssh, local fs, http, svnserve... all which allow per-user permissions in any recent version. Grandparent just didn't rtfm.

Re:CVS-Subversion anyone?

[nuba]

Alright that was a little harsh :P To clarify, you can do it with things like multiple instances of svnserve and group permissions. Through apache2 it is simple with the authz module.

Re:CVS-Subversion anyone?

[ldspartan]

I was trying to be nice :).

--
lds

Re:CVS-Subversion anyone?

[Bothari]

Your 99% right except except for :

This issue has been beaten to death several times on the mailing lists. Please read the archives.

If the issue has been "beaten to death ... in the mailing lists" then it should be part of the faq's/docs/manual. Read the mailing lists is not an answer to a question, specially if the mailing list is quite active and has archives going back years...

On the other hand, most of his complaints are answered right on the manual, so i don't get his problem either...

Re:CVS-Subversion anyone?

[Anonymous Coward]

But unfounded claims such as yours shouldn't need to be addressed several times per week

If people are making these claims several times per week, then perhaps the documentation is lacking or hard to find. A more extensive CVS-to-SVN conversion FAQ might help to address these problems.

Re:CVS-Subversion anyone?

[jilles]

I think the reverse question is more relevant. Why exactly are you sticking with obsolete stuff like CVS? Maybe you have valid reasons (i.e. maybe there's something that should be implemented in subversion)?

I use subversion on a daily basis and I find it is much less a PITA than CVS which we still use for older projects (we never did a migrate but just started using subversion for the new stuff).

Fast & painless merges, branches & tags, transactional commits, versionmanaged file & directory names are some of the advantages are some of the reasons you should be adopting subversion.

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?

Re:CVS-Subversion anyone?

[DylanQuixote]

You do:

easy:

svn checkout -r 124 $REPO/trunk
svn cp trunk/ $REPO/tag/bug42fix

So $REPO/tag/bug42fix is $REPO/trunk at revision 124 forever, until the end of time. Or until you delete it.

If you commit to that tag, it becomes a branch.

Also, copying is light-weight. Even if /trunk is 20MB, the copy will only use a few kilobytes of repository space.

So, a tag is a copy you don't commit to, and a branch is a copy you commit to. Tags don't even have to be under /tags, but that's what most people do. the SVN book covers this is great detail.

Re:CVS-Subversion anyone?

[Anonymous Coward]

The very fact that there is confusion over these things and that its dependant on specific versions of so many other things really does point out that Subversion is still maturing, both in design and in packaging.

Our company looked at it and backed away because it would take at least a days work to get it all setup and it would require a nonstandard system load. That needs to be addressed regardless of how good anyone says SVN is before I consider it a fully mature ready for the masses replacement for CVS.

Free book online

[prostoalex]

There's a free online version of O'Reilly's Version Control with SubVersion

Re:Free book online

[nuba]

PTR is working on a Subversion book in the Bruce Perens Open Source series. They've sent me a couple chapters to review and it looks like its coming along. It's still a ways off, but it should be nice once its released.

here is a good example

[Da_Slayer]

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)

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:SVK. :-)

[Anonymous Coward]

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.

Sounds like something worth checking out!!

Let's see:

% emerge -pv svk

These are the packages that I would merge, in order:

Calculating dependencies
emerge: there are no masked or unmasked ebuilds to satisfy "svk".

Uh oh..bit of a problem. I'm too lazy to install from sources... hmm wait a minute!

% ssh freebsdbox portell svk
/usr/ports/devel/svk/pkg-descr reads:

svk is a decentralized version control system written in Perl.
It uses the subversion filesystem but provides additional features:

- Offline operations like checkin, log, merge.
- Distributed branches.
- Lightweight checkout copy management (no .svn directories).
- Advanced merge algorithms, like star-merge and cherry picking.

WWW: http://svk.elixus.org/

woohoo!!!

Re:SVK. :-)

[Anonymous Coward]

I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

It's a source code control system. There is just no way I'm going to consider entrusting my source code to it until the developer has enough confidence in its stability to call it version 1.0. (And when I say stability, I don't just mean likelihood of crashes; I mean whether the file formats, interfaces, etc. are in flux.)

Stupid links suck

[Anonymous Coward]

You know what sucks? When /. stories have links to stupid things in them. E.g. a link from "released" to the tarball, instead of a release announcement.

Re:Stupid links suck

[Anonymous Coward]

I'm glad I wasn't the only one thinking that was dumb.

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). :)

Re:No more BerkeleyDB!

[noselasd]

Why is the new fsfs repository such a big deal ?(unless you do store it on network filesystems?)

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!"

And can it do hot backup, with guaranteed atomicity ?

Re:No more BerkeleyDB!

[nthomas]

Why is the new fsfs repository such a big deal ?(unless you do store it on network filesystems?)

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

Re:No more BerkeleyDB!

[nuba]

BDB can have issues across different builds. You cannot just tar up a repositor, send it somewhere else, and expect them to be able to use it. Also, certain versions of BDB that distros ship have been known to cause problems. A lot of the issues on the mailing list are caused by BDB. If a BDB file is corrupted, you lose everything. FSFS keeps revisions as files I believe. This means _should_ anything go wrong (is very rare as is) the damage should be contained to the last revision.

Re:No more BerkeleyDB!

[renoX]

> Which brings up the question, why do you want your repositories to be human editable? [cut] with XXX, that's guaranteed not to happen.

Yeah, right with *any XXX* corruptions can and will happen (rarely yes, but it will) unless your SW is garanteed to be bugfree..

Note that even with a human editable SW, the corruption can be so severe that you can't fix it (or it is time consuming).

So backup..

Re:No more BerkeleyDB!

[DittoHead]

If you want to send a repository, or a portion of a repository, for use elsewhere, just dump the data using the "svnadmin dump" command. The recipient can put the data into a new repository with the "svnadmin load" command.

The existence of a repository, or a database storage component in the repository, does not relieve you of the necessity of making backups of the repository.

Re:No more BerkeleyDB!

[KieranElby]

Which brings up the question, why do you want your repositories to be human editable?

I find "grep -ri blah /../cvsroot" rather useful. I suspect I'm not the only one.

Re:No more BerkeleyDB!

[noselasd]

True, but it was never meant to do things like this.
Btw, what would taring up your repos do if someone happened to
commit at that point ?
svn ships a tool that (atomically) dumps the db in a textual representation, to be able to load it back regardless of platfor/version trouble.

Re:No more BerkeleyDB!

[Anonymous Coward]

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.

No, it's not guaranteed not to happen. With software, nothing is ever guaranteed not to happen. Subversion is not a perfect piece of software that can never have a bug. Subversion does not run on computers where it's impossible for the hardware to fail or for someone to hit the reset or power switch. Subversion does not have a magic way to guarantee that someone won't unknowingly try to run it from backups that were taken while its files were actively being modified.

The fact that you seem to believe otherwise and that you seem to know about subversion makes me want to investigate whether you are a significant contributor to the subversion project. If so, then I would start to wonder whether the entire subversion project is insufficiently paranoid. (Actually, I already do wonder since I'm not a huge fan of Berkeley DB either, for similar reasons.)

Other reasons...

[MobyDisk]

Transactional database format
True client - server
Encrypted passwords
Built-in SSH support

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:FSFS

[nuba]

Yes, FSFS is a big deal. I'm looking forward to migrating my customers over once it gets a little more real world testing :) BDB although great overall is the source of a pretty large number of the problem emails on the mailing list.

distributed systems are more interesting

[ijones]

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.

Re:distributed systems are more interesting

[DylanQuixote]

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

Re:distributed systems are more interesting

[Anonymous Coward]

Perl is a terrible language to write mission-critical applications in.

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?

Re:How does it compare to Arch?

[xiox]

I've tried both. Subversion is good as a drop-in replacement for CVS. Arch is probably better when you have distributed development. I use Arch most of the time, but the main problem with it is that it is pretty difficult to use at first, and that it uses rather strange file naming convention.

Arch has the advantage of being very small and light. Your change data gets stored in simple .tar.gz files, so it's very easy to recover and backup if things go wrong.

I can't comment on the supposed design problems with Subversion, but it appears a bit limited compared to the capabilities of arch.

Cool

[Dreadlord]

Cool, I'll download the latest version from the project's CVS ;)

Re:Cool

[Anonymous Coward]

For the clueless who modded this troll, Subversion is a version control system just like CVS.

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

Re:What's with all the dependancies?

[Narchie Troll]

You don't need to install any special custom versions of anything for SVN. The only semi-unusual requirements are neon and apr. It works fine with vanilla Apache 2. You don't need to install Apache support if you don't want it, either -- I remember specifically choosing to install it.
And vanilla berkdb is indeed 'good enough'.

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

So the programs...

[2mcm]

subversion is ??

Re:So the programs...

[Anonymous Coward]

A way of distinguishing between more improved and less improved submarines using the same basic model.

OK, that was a joke.
Actually, subversion is a revision/version control system, along the lines of RCS and CVS.

Nice new feature:

[captainclever]

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

Here you go...

[Phil John]

...the free, online version of the O'Reilly subversion book.

The documentation is not lacking, people are just too damn lazy to google for it or follow the links on the subversion site at tigris.

Application programming

[E_elven]

I really hope they've changed the API around...damn.

I swear, when I find out who decided to call every damn parameter in the entire damn thing a 'baton'.

I hope they'll have a developer conference soon, I'll be bringing my 'baton' along.

Easy

[lorcha]

If you want to kill your brain cells writing code, use svn.

If you want to kill your brain cells figuring out how to use your frickin' code repository and have no brain cells left for coding, use arch.

HAHAHAHAHHAH FUNNY!!!!!!

[lorcha]

If you really want to check out a working copy of the master sources:

$ svn co http://svn.collab.net/repos/svn/trunk subversion

HTH. HAND.