4 ms·

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

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.

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.