5 ms·

If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer. However, it'

If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer. However, it's also clear that svn is a hugely important project, not just for legacy reasons but also to provide certain benefits (mostly around simplicity and control) that many organizations need. But SVN itself has none of those needs, it's an open source project of the nature for which git was specifically designed. So I'd think any rational developer would say it's perfectly reasonable for SVN development to use git. All else being equal, of course dogfooding is ideal, but in this case all else is clearly not equal.

gecko 13y ago
If any SVN dev truly believes that svn is better than Git in any technical sense then I wouldn't trust the engineering judgment of that developer. Hi. Small-time Mercurial contributor and Kiln founder. I use both Git and Mercurial in my daily workflow, and only on very rare occasions touch Subversion. Subversion is better than Git and Mercurial in at least several key areas: 1. Access controls. While this is not necessary for individual products, or even many companies, only Subversion offers the kinds of access controls that some large companies require. While you can *work around* that by sharding your code into tons of repositories, not all companies want to do that, and I don't honestly blame them. 2. Very large repositories. Facebook's work on Mercurial finally allows Mercurial to scale to those sizes (with significant trade-offs), but Git still cannot. 3. Very large files. Game companies in particular need to do asset management. Subversion can work with large files directly, Mercurial can kind of "fake out" working with them directly through largefiles, and Git forces you to use a third-party tool like Git annex with a custom workflow. 4. Interop with legacy tools. Subversion repositories can be accessed trivially with WebDAV, which, while I honestly think is mostly a antifeature, does allow random people in your office to trivially access things in Subversion directly via Finder/Gnome/Windows WebDAV support (and even commit, with proper settings, simply by saving). Just because Subversion doesn't use Git's branching system and isn't distributed doesn't mean it's totally without merit, and someone so wrapped up in Git's ecosystem that they can find no merit left in Subversion is a developer who likely has an irrational approach to evaluating systems.
- pswenson 13y ago
  also, you can sync to a subdirectory in SVN - not git. 1) yeah, although I question the sanity of doing this. 2) is this related to #3? 3) yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo. But you are right - putting giant files in git is a terrible idea, especially if you change them often.
  - masklinn 13y ago
    > yeah, although I question the sanity of doing this. the sanity of access control? > is this related to #3? Not necessarily. > yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?
    - pswenson 13y ago
      >the sanity of access control? only at a directory level, git has it at a repo level. >Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable? no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. the assets are fetched from the artifact repo. there pros and cons of course...
      - masklinn 13y ago
        > no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. Yes, that's "essentially unsyncable" when you have thousands of assets and have to keep them synchronised by hand. It has the same sanity as considering tarballs to be a good version-control scheme. > there pros and cons of course... I see no pros compared to a VCS which can handle code and other assets in the same repository and keep them naturally synchronised by virtue of them being naturally synchronised.
oneeyedpigeon 13y ago
SVN has PHP bindings, git doesn't. No matter what you think of PHP or SVN, it's difficult to argue that there is no single use case which wouldn't be affected by this (I myself have recently had to choose SVN for a project for this very reason).
- phaemon 13y ago
  Isn't https://github.com/libgit2/php-git https://github.com/libgit2/php-git what you're looking for?
  - Xylakant 13y ago
    you're certainly aware that libgit2 is a reimplementation of git, largely sponsored by github since the original git libraries are binding-unfriendly to say the least. The de-facto ruby "bindings" (grit) were a mere wrapper around cli git and afaik this used to be the only way to go. I tried to use libgit2 for a project last year and a coworker did a couple of patches and I can say that there's still a lot of ground to cover until libgit2 is at least somewhat feature complete. Back then, clone via SSH and other _must_have_ features were unimplemented.
    - phaemon 13y ago
      How unlucky, you must have just missed it. Clone via ssh was added in May last year! What were the other must-haves that were missing?
    - emmelaich 13y ago
      Linus uses libgit2 [0] albeit as a data format, not as a basis for VCS. [0] https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
- dasil003 13y ago
  And surprise! I did not argue that. I wish people would read my comment a bit more carefully.

gecko 13y ago

If any SVN dev truly believes that svn is better than Git in any technical sense then I wouldn't trust the engineering judgment of that developer. Hi. Small-time Mercurial contributor and Kiln founder. I use both Git and Mercurial in my daily workflow, and only on very rare occasions touch Subversion. Subversion is better than Git and Mercurial in at least several key areas: 1. Access controls. While this is not necessary for individual products, or even many companies, only Subversion offers the kinds of access controls that some large companies require. While you can *work around* that by sharding your code into tons of repositories, not all companies want to do that, and I don't honestly blame them. 2. Very large repositories. Facebook's work on Mercurial finally allows Mercurial to scale to those sizes (with significant trade-offs), but Git still cannot. 3. Very large files. Game companies in particular need to do asset management. Subversion can work with large files directly, Mercurial can kind of "fake out" working with them directly through largefiles, and Git forces you to use a third-party tool like Git annex with a custom workflow. 4. Interop with legacy tools. Subversion repositories can be accessed trivially with WebDAV, which, while I honestly think is mostly a antifeature, does allow random people in your office to trivially access things in Subversion directly via Finder/Gnome/Windows WebDAV support (and even commit, with proper settings, simply by saving). Just because Subversion doesn't use Git's branching system and isn't distributed doesn't mean it's totally without merit, and someone so wrapped up in Git's ecosystem that they can find no merit left in Subversion is a developer who likely has an irrational approach to evaluating systems.

pswenson 13y ago
also, you can sync to a subdirectory in SVN - not git. 1) yeah, although I question the sanity of doing this. 2) is this related to #3? 3) yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo. But you are right - putting giant files in git is a terrible idea, especially if you change them often.
- masklinn 13y ago
  > yeah, although I question the sanity of doing this. the sanity of access control? > is this related to #3? Not necessarily. > yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?
  - pswenson 13y ago
    >the sanity of access control? only at a directory level, git has it at a repo level. >Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable? no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. the assets are fetched from the artifact repo. there pros and cons of course...
    - masklinn 13y ago
      > no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. Yes, that's "essentially unsyncable" when you have thousands of assets and have to keep them synchronised by hand. It has the same sanity as considering tarballs to be a good version-control scheme. > there pros and cons of course... I see no pros compared to a VCS which can handle code and other assets in the same repository and keep them naturally synchronised by virtue of them being naturally synchronised.

oneeyedpigeon 13y ago

SVN has PHP bindings, git doesn't. No matter what you think of PHP or SVN, it's difficult to argue that there is no single use case which wouldn't be affected by this (I myself have recently had to choose SVN for a project for this very reason).

phaemon 13y ago
Isn't https://github.com/libgit2/php-git https://github.com/libgit2/php-git what you're looking for?
- Xylakant 13y ago
  you're certainly aware that libgit2 is a reimplementation of git, largely sponsored by github since the original git libraries are binding-unfriendly to say the least. The de-facto ruby "bindings" (grit) were a mere wrapper around cli git and afaik this used to be the only way to go. I tried to use libgit2 for a project last year and a coworker did a couple of patches and I can say that there's still a lot of ground to cover until libgit2 is at least somewhat feature complete. Back then, clone via SSH and other _must_have_ features were unimplemented.
  - phaemon 13y ago
    How unlucky, you must have just missed it. Clone via ssh was added in May last year! What were the other must-haves that were missing?
  - emmelaich 13y ago
    Linus uses libgit2 [0] albeit as a data format, not as a basis for VCS. [0] https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
dasil003 13y ago
And surprise! I did not argue that. I wish people would read my comment a bit more carefully.