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"

Free book online

[prostoalex]

There's a free online version of O'Reilly's Version Control with SubVersion [red-bean.com]

Re:CVS-Subversion anyone?

[ebash]

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

here is a good example

[Da_Slayer]

The apache webserver [apache.org] is switching to subversion. This was said in the mailing list post here [theaimsgroup.com] 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 [apache.org]

Useful links: Subversion homepage [tigris.org]

Version Control with Subversion Book (mirror) [rush3d.com]

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.

Other reasons...

[MobyDisk]

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

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.

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 [mit.edu] 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

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 [gnuarch.org], or if you're looking for something with a better learning curve, darcs [abridgegame.org] is really cool, and is implemented in the glorious Haskell programming language [haskell.org].

Distributed systems like these have a lot of advantages over the CVS/SVN model.

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. [mit.edu]

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

Re:distributed systems are more interesting

[DylanQuixote]

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

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?

[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: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'.

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