4 ms·

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

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.

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.