Comment by mmastrac | Hacker News Reader

Comment by mmastrac | Hacker News Reader

I probably should have linked to the release notes instead, which are available here:

http://subversion.apache.org/docs/release-notes/1.7.html

Some big changes in 1.7 extracted from the release notes:

Working Copy Metadata Storage Improvements

A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every directory in the working copy, Subversion 1.7 working copies have just one .svn directory—in the root of the working copy. This directory includes (among other things) an SQLite-backed database which contains all of the metadata Subversion needs for that working copy.

svn patch

Subversion 1.7 features a new subcommand called svn patch which can apply patch files in unidiff format (as produced by svn diff and other diff tools) to a working copy.

Improved HTTP protocol usage

Subversion 1.7 offers a simpler HTTP protocol variant that can be used when connecting to supported servers. This simpler protocol (sometimes referred to as HTTPv2) requires fewer client-server round trips to establish a connection, making Subversion much more performant on high-latency network connections.

I'm not trolling here, this is a genuine question:

What are the advantages of using SVN over Git? (assuming one was starting a new project and hadn't yet chosen a VCS)

One big one is that you can check out a working copy of a particular sub-path in the repository. This means you don't need the whole repo (or the repo's entire history) locally, which is necessary in workflows where build products and other giant binaries are stored in version control.

I believe this is why many people still use Subversion and Perforce, etc.

Of course, this is probably a not-so-great reason for doing so and reflects an inability to change build procedures/organizational workflows if this feature is absolutely vital.

This is actually a really cool feature. Basically, you can have one large repository to administer instead of lots of smaller ones, and you can treat any subdirectory level as a single repository.

Want to checkout all Apache Software Foundation projects?

    svn checkout http://svn.apache.org/repos/asf/

Want to work on Apache httpd?

    svn checkout http://svn.apache.org/repos/asf/httpd/

Maybe you only care about mod_proxy?

    svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/

Apache server becomes a subproject of the new Apache MegaOS? Just move /repos/asf/httpd/ to /repos/asf/megaos/httpd.

See also FreeBSD repository: http://svnweb.freebsd.org/base/

> Want to checkout all Apache Software Foundation projects? > svn checkout http://svn.apache.org/repos/asf/

Correction, that's all branches and all tags of all ASF projects. Not useful.

> Want to work on Apache httpd? > svn checkout http://svn.apache.org/repos/asf/httpd/

Again, all versions and all tags thereof.

> Maybe you only care about mod_proxy? > svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/pr...

That's just the one version.

Similarly, my project wants the latest sources under under specific branches from repositories from five different administrative domains. That's trivial in git. I can move them around freely, lock a revision of a particular repository while letting others move forward, have custom (potentially unpublished or unwelcome upstream) patches to fit into my build system or supported OSes that are tracked along with them.

Subversion has externals for this same reason. It's no excuse for poor repository management.

> Correction, that's all branches and all tags of all ASF projects. Not useful.

Yes, I should have used the FreeBSD repository as an example, which is not organized in {trunk,branch,tags} form.

Version control doesn't need to be restricted to code and builds. In my previous startup we revisioned all of our hardware schematics, product manuals, BOMs, etc. Most of it was binary data, so we didn't gain much from diffing. But we had a process in place, required for most forms of documentation control. And it worked exceptionally well (with the obvious caveat two people couldn't work on the same file at the same). Being able to check out just the component you needed to work on was great. git absolutely would have fallen apart in this case and dropping version control wasn't an option.

I don't know enough about your domain to make a coherent statement. Maybe the SVN style is superior for it, but I thought we were talking about code, which is why I was talking about build processes.

Two simpler use cases:

* Using a big repository for a bunch of related projects. Settings up a new project (not a new repository, but who can tell the difference?) is as simple as creating a new folder, then commiting it. Then you can directly checkout that folder if you need the single project. This beats SSH one-liners to set up new repositories.

* I usually have something like a "httpdocs"/"website" subfolder in my bigger projects. With svn, I just check out that folder on my web server. With git, I'd have to check out the whole project, which feels more like a kludge.

Setting up a SVN server takes seconds (infact it comes pre installed on all macs). Setting up a git server is a nightmare. If you have a small team like me (2-3 people max) then SVN easily meets all your needs.

Naturally Git will catch up and supersede but currently they are focusing on other stuff.

Why is it a nightmare? You just run `git init --bare` and it all just works. SSH provides authentication, the filesystem provides authorisation.

As I remember, svn is more complicated, it has that separate svnadmin tool and relies on you to craft a suitable directory structure.

Setting up both Subversion and Git repos (with access control for multiple users) is pain compared to Fossil ;-)

I'm not going to say you're wrong, I just haven't had a install work as advertised yet. I was initially put off when I tried to install it on my Windows workstation, check out this tutorial for how much of an annoyance it is :

http://www.timdavis.com.au/git/setting-up-a-msysgit-server-w...

I tried on another ubuntu machine and it just kept failing, I tired around 4 walk throughs and none of them completed... why I'm not sure.

After reinstalling that ubuntu machine after each failure I gave up and went back to SVN because it is already configured on my laptop, and I decided I might as well just use the hackintosh/OSX86 install on my workstation as its primary work environment and use SVN server already available.

I'll try git again at some stage, but I just haven't got enough spare time to spend hours debugging where things aren't as I'd expect at the moment.

If you're hosting the repository on a UNIX machine with git installed, it's literally as simple as:

mkdir repository cd repository git init

Then on the client side:

git add serverRemote ssh://user@host.com/path/to/repository

I'm not surprised that it's difficult on Windows, since this simple approach relies on so much stuff that doesn't come with Windows, but on a UNIX server it shuold be really straightforward. Much easier than setting up Subversion in my experience.

If you end up trying to setup git on a linux machine, two things:

- setup or have available another linux machine to act as a "client". git on windows with ssh can be a bit fidgety sometimes, and that would help you debug whether it's a client or server issue.

- do look at gitolite for managing the repos [1]. Its "simple" to install, and the features it brings to the table are awesome (from private 'scratch' repos to auth and key management, and several others).

[1] - https://github.com/sitaramc/gitolite#_quick_install

I use them both as well as Mercurial. My favorite is subversion, but that's only because I've been using it for years. The one thing I admire most about git is its branching. You can experiment very easily with crazy ideas and just throw away the branch if it doesn't work out. Learn them both and pick the one that works best for you. But you should be able to use any of them. From old-fashioned CVS (which is still widely used in industry) to git because as a professional programmer, you never know what your next employer or start-up buddy will be using. And really, they all share many things in common once you get past the new-fangled distributed features.

Edit: I should also mention that I prefer subversion's central repository approach and that I don't really need the distributed features of git but I can understand why Linus and kernel hackers do!

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but who are nevertheless producing content that will appear on our website somewhere (e.g. static content).

Really?

I used Subversion for over 4 years and suffered through the regular merge issues, connectivity issues ("huh, can't commit because I'm not connected"), line ending issues, you name the problem I had it.

Two days into using Mercurial I felt more confident with it than I had ever felt with Subversion. I could branch code without having to work with the server, I could commit on my own machine and later push changes... and the merges just worked. No praying for ten minutes, no stupid CR/LF vs. CR errors, nothing.

I guess you'd have a point about easy of use if you count on the excellent TortoiseSVN. In the beginning Mercurial and Git didn't have anything as nice as that.

The kinds of people we provide SVN for have almost no technical skills whatsoever. You could spend a month trying to explain what a merge was and they wouldn't understand.

But they do need to produce content (which they'd like to be version controlled) that they expect my team to put up on our website.

From our point of view, SVN is a near-perfect solution: explain how to check $SOMETHING out and how to check it back in when you've amended it (using the excellent TortoiseSVN).

Once they've checked their work back in they email our team email address and one of us runs SVN UP on the relevant server, and we're done.

How are you safe from CR/LF vs. CR errors in Mercurial?

I'm curious, because at least Git does not protect you from CRLF-problems out of the box. All the committers must have right settings (autocrlf=input for unix and true for Windows). In case of a central repository, you probably should have a protection hook in case someones settings get changed anyways.

SVN handles large binaries with ease. I'm an EE, and these are frequent occurrences in my projects. Git can choke on big binaries.

In my experience, if you are writing a game and you have artists committing assets to your repository, git can be very difficult to work with because it requires quite a bit of training to handle properly. SVN is something they're more used to.

Submodules are a good approach for separating large assets from the code repository.

Please elaborate on "training". Do users check in things they shouldn't? Complain that clones take forever because of the sheer size of the files in a tree? Something else?

It's more about learning how to deal with git's error messages. They are very cryptic if you don't have a complete understanding of how the underlying system works.

Is SVN just slowly evolving DVCS features? That seems to be the progression I've been noticing.

It appears so. This is good for SVN users - moving large codebases with years of commits, along with the associated build scripts and deployment data can be a big hassle. And that's before you factor in the effort required to move all of the users over.

I wouldn't be surprised if we see 'offline' commits in SVN.

No. They decided to focus on being the best centralized version control system: http://lwn.net/Articles/381794/

That seems like a sensible vision for SVN, but it begs the question is there really still a need for centralized version control?

While switching to a single .svn directory seems good, there's also a feature lost: you can no longer move parts of your working trees around the filesystem without hassle.

This is dangerous and error prone... What use case are you solving for by doing that?

Use case... just moving stuff around. It was nice to have the freedom to treat any subdirectory as a separate working copy. Why is this dangerous? (note: I no longer use Subversion).

The system wasn't designed with that consideration in mind, locking mechanisms can break when you do this and don't know that the folder is in use by another system (functionality varies per OS). If you are moving files to reorganize structure of a project, the .svn folders will cause conflicts, and you'll also loose the history of the move, (instead a continuous history of that structure, it'll appear as a new structure)

Lastly, when supporting my developer pool with SVN, resolving corrupted .svn folders because of moving folders in correctly is a time consuming procedure and usually ends with an export command to kill all the .svn files, and risking blowing away changes in with a commit that ignores history.

Reply on news.ycombinator.com