4 ms·

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 chose

by udp 15y ago

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)

metajack 15y ago
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.
- DannoHung 15y ago
  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.
  - dchest 15y ago
    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/ http://svnweb.freebsd.org/base/
    - dlsspy 15y ago
      > Want to checkout all Apache Software Foundation projects? > svn checkout http://svn.apache.org/repos/asf/ 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/ 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/proxy/ 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.
      - dchest 15y ago
        > 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.
  - nirvdrum 15y ago
    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.
    - DannoHung 15y ago
      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.
- gurkendoktor 15y ago
  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.
rjd 15y ago
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.
- JonnieCache 15y ago
  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.
  - dchest 15y ago
    Setting up both Subversion and Git repos (with access control for multiple users) is pain compared to Fossil ;-)
  - rjd 15y ago
    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-with-copssh-on-windows 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.
    - mikeash 15y ago
      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.
16s 15y ago
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!
arctangent 15y ago
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).
- dguaraglia 15y ago
  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.
  - arctangent 15y ago
    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.
  - Aga 15y ago
    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.
reemrevnivek 15y ago
SVN handles large binaries with ease. I'm an EE, and these are frequent occurrences in my projects. Git can choke on big binaries.
fragsworth 15y ago
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.
- lucisferre 15y ago
  Submodules are a good approach for separating large assets from the code repository.
- hyperrail 15y ago
  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?
  - fragsworth 15y ago
    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.

by udp 15y ago

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)

metajack 15y ago

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.

DannoHung 15y ago
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.
- dchest 15y ago
  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/ http://svnweb.freebsd.org/base/
  - dlsspy 15y ago
    > Want to checkout all Apache Software Foundation projects? > svn checkout http://svn.apache.org/repos/asf/ 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/ 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/proxy/ 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.
    - dchest 15y ago
      > 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.
- nirvdrum 15y ago
  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.
  - DannoHung 15y ago
    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.
gurkendoktor 15y ago
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.

rjd 15y ago

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.

JonnieCache 15y ago
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.
- dchest 15y ago
  Setting up both Subversion and Git repos (with access control for multiple users) is pain compared to Fossil ;-)
- rjd 15y ago
  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-with-copssh-on-windows 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.
  - mikeash 15y ago
    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.

16s 15y ago

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!

arctangent 15y ago

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

dguaraglia 15y ago
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.
- arctangent 15y ago
  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.
- Aga 15y ago
  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.

reemrevnivek 15y ago

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

fragsworth 15y ago

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.

lucisferre 15y ago
Submodules are a good approach for separating large assets from the code repository.
hyperrail 15y ago
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?
- fragsworth 15y ago
  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.