5 ms·

SVN Devs thought: haha, no one will really believe we would not prefer SVN rest of the world thought: man, is SVN really so bad that even the devs won't use i

by eik3_de 13y ago

SVN Devs thought: haha, no one will really believe we would not prefer SVN rest of the world thought: man, is SVN really so bad that even the devs won't use it? That's sad, but hey, they're responsible developers choosing the best tool for the job. now that we know it was a joke, are we more convinced that SVN is great?

untothebreach 13y ago
I would think that people who already thought SVN is great probably continued thinking SVN is great, and people who thought otherwise, continue to think otherwise. I currently have to use both in my job, and look forward to when our conversion to git is complete.
- silon3 13y ago
  Imo the core of git is superior, but the command line interface of SVN is much better. Git is just horribly messy. The distributed stuff push/pull had a lot of work and improvements, but the work/commit cycle is just messy, at least when compared to SVN or mercurial.
  - untothebreach 13y ago
    That's fine, I just happen to respectfully disagree :) I started with git though, so I'm sure that has something to do with it. I learned and used git for quite a while before I had to use svn for work, and I found myself very annoyed with certain svn-isms.
dasil003 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. 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?

by eik3_de 13y ago

untothebreach 13y ago

I would think that people who already thought SVN is great probably continued thinking SVN is great, and people who thought otherwise, continue to think otherwise. I currently have to use both in my job, and look forward to when our conversion to git is complete.

silon3 13y ago
Imo the core of git is superior, but the command line interface of SVN is much better. Git is just horribly messy. The distributed stuff push/pull had a lot of work and improvements, but the work/commit cycle is just messy, at least when compared to SVN or mercurial.
- untothebreach 13y ago
  That's fine, I just happen to respectfully disagree :) I started with git though, so I'm sure that has something to do with it. I learned and used git for quite a while before I had to use svn for work, and I found myself very annoyed with certain svn-isms.

dasil003 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. 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?