4 ms·

I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I'

by compay 17y ago

I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I've forgotten how to do some things. IMHO unless you have a good reason to use SVN, you really should be using some kind of DVCS. SVN compared to Git/Mercurial/etc is like nano compared vim or emacs. I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like. But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.

axod 17y ago
Still generalizing IMHO. Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs. Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.
- zaphar 17y ago
  Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of: * faster * more featureful I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
  - sid0 17y ago
    When you want to lock binary files as "being edited". DVCSes by design cannot lock files. edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
  - axod 17y ago
    One off the top of my head: From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
    - steveklabnik 17y ago
      You can also only check out the history to a certain depth, if this is a problem.
  - compay 17y ago
    To me the only good reasons to use SVN at this point are cultural. For example, your project can't afford the time to make the switch, or your organization has some useful tools built around SVN that would cost time and money to replace. Like I said earlier, "because I want to" is a also valid reason, just not a good one. @axod, Git repos take up way less space on disk than SVN because its compression and diffing is much better than SVN's. This is one of the first things you read in most Git FAQ's. If you're not aware of that, it indicates you've barely given Git a serious look. If you haven't given it a serious look, I don't understand why you are arguing against it so passionately. I'm guessing you dislike the (admittedly annoying) hype around Git more than Git itself.
    - axod 17y ago
      Put some videos in svn and in git. update them 100 times to different videos each time. The git repos now has 100 separate sets of video files, which will compress poorly. The svn checkout has one set of videos. The svn local checkout is likely to be far smaller than the git one. Is the above true, or false. If false, why? You're right though, I dislike the hype and the suggestion that it in some way matters. Sure, use revision control, but is it really going to speed up your software dev moving to something else? maybe, maybe not. Is it going to impact the chances of success for your startup? probably not.
      - compay 17y ago
        Yeah, you're right that in this case SVN would have a smaller checkout size. So if this is something that you need then SVN would be a clear winner here in terms of disk storage. However, with the more typical usage pattern of a repository of mostly code and perhaps a handful of smallish binary files, Git is almost always going to have a smaller checkout size despite including the version history. I also think in this case the difference is like being shot in the stomach, or being shot in the knee. Both SVN and Git are going to give you serious pain.
        axod 17y ago
        In the name of science I'm converting the Mibbit repos from svn to git to see what the size difference actually is on a typical repos (I don't have videos in there ;) Be interesting to see if svn is really that inefficient... Who knows, maybe I'll try a few git commands :/
  - deleted 17y ago
    [deleted]
  - seiji 17y ago
    1. Dealing with large art/graphics/asset repositories. Having every artist with a private 50GB+ repository is unmanageable (especially when the artists can't be bothered to understand why add->commit->push is necessary). 2. Dealing with SOX compliance with regard to shipping software. You are required to keep a lot of redundant compiled files around.
  - tremendo 17y ago
    Hm, only Subversion so far has good and "easy" GUI integration over all platforms. GIT's only failing on Windows, or Mercurial's on the Mac. For a multi-level of expertise, multi-platform, multi-disciplinary team (front-end, back-end, flash developers) working on Macs, Windows and Linux boxes, it seems to me SVN is still the path of least resistance. Much as I hate it.
- deleted 17y ago
  [deleted]
statictype 17y ago
Serious question: What benefits would a single developer working in isolation derive from using a distributed version control system? And what if that developer was running an OS like Windows? Does git have first-class support for Windows? Would such a developer still see any advantage to using git?
- compay 17y ago
  Git's easy branching is a huge benefit for working on new features/refactorings in isolation. It is much easier than SVN's. Git works fine on Windows, take a look at: http://code.google.com/p/msysgit/ http://code.google.com/p/msysgit/
- graywh 17y ago
  No need to set up a central repository. Your full history resides in your working copy.
- FooBarWidget 17y ago
  I can't say for all distributed version control systems, but in case of git, it's extremely easy to setup a new repository. Create a new directory, type 'git init', and you're good to go. This compared to Subversion's insistence to setup a repo directory elsewhere and then checking that out. I save about 3 minutes (including time to ssh to a remote server to create the repository), but those 3 minutes feel very painful so I didn't create repositories until I've written a fair amount of code. Now I create a repository almost from the start. Branching and merging is very useful even for single developers. It's not the number of developers, it's the size of the project. For larger projects I'll want to branch often to experiment with things. I can delete the branch after I'm done with the experiment. As for Windows support: I've heard that Msys-Git is in a very good shape today. I haven't used it myself though.

by compay 17y ago

axod 17y ago

Still generalizing IMHO. Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs. Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.

zaphar 17y ago
Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of: * faster * more featureful I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
- sid0 17y ago
  When you want to lock binary files as "being edited". DVCSes by design cannot lock files. edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
- axod 17y ago
  One off the top of my head: From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
  - steveklabnik 17y ago
    You can also only check out the history to a certain depth, if this is a problem.
- compay 17y ago
  To me the only good reasons to use SVN at this point are cultural. For example, your project can't afford the time to make the switch, or your organization has some useful tools built around SVN that would cost time and money to replace. Like I said earlier, "because I want to" is a also valid reason, just not a good one. @axod, Git repos take up way less space on disk than SVN because its compression and diffing is much better than SVN's. This is one of the first things you read in most Git FAQ's. If you're not aware of that, it indicates you've barely given Git a serious look. If you haven't given it a serious look, I don't understand why you are arguing against it so passionately. I'm guessing you dislike the (admittedly annoying) hype around Git more than Git itself.
  - axod 17y ago
    Put some videos in svn and in git. update them 100 times to different videos each time. The git repos now has 100 separate sets of video files, which will compress poorly. The svn checkout has one set of videos. The svn local checkout is likely to be far smaller than the git one. Is the above true, or false. If false, why? You're right though, I dislike the hype and the suggestion that it in some way matters. Sure, use revision control, but is it really going to speed up your software dev moving to something else? maybe, maybe not. Is it going to impact the chances of success for your startup? probably not.
    - compay 17y ago
      Yeah, you're right that in this case SVN would have a smaller checkout size. So if this is something that you need then SVN would be a clear winner here in terms of disk storage. However, with the more typical usage pattern of a repository of mostly code and perhaps a handful of smallish binary files, Git is almost always going to have a smaller checkout size despite including the version history. I also think in this case the difference is like being shot in the stomach, or being shot in the knee. Both SVN and Git are going to give you serious pain.
      - axod 17y ago
        In the name of science I'm converting the Mibbit repos from svn to git to see what the size difference actually is on a typical repos (I don't have videos in there ;) Be interesting to see if svn is really that inefficient... Who knows, maybe I'll try a few git commands :/
- deleted 17y ago
  [deleted]
- seiji 17y ago
  1. Dealing with large art/graphics/asset repositories. Having every artist with a private 50GB+ repository is unmanageable (especially when the artists can't be bothered to understand why add->commit->push is necessary). 2. Dealing with SOX compliance with regard to shipping software. You are required to keep a lot of redundant compiled files around.
- tremendo 17y ago
  Hm, only Subversion so far has good and "easy" GUI integration over all platforms. GIT's only failing on Windows, or Mercurial's on the Mac. For a multi-level of expertise, multi-platform, multi-disciplinary team (front-end, back-end, flash developers) working on Macs, Windows and Linux boxes, it seems to me SVN is still the path of least resistance. Much as I hate it.
deleted 17y ago
[deleted]

statictype 17y ago

Serious question: What benefits would a single developer working in isolation derive from using a distributed version control system? And what if that developer was running an OS like Windows? Does git have first-class support for Windows? Would such a developer still see any advantage to using git?

compay 17y ago
Git's easy branching is a huge benefit for working on new features/refactorings in isolation. It is much easier than SVN's. Git works fine on Windows, take a look at: http://code.google.com/p/msysgit/ http://code.google.com/p/msysgit/
graywh 17y ago
No need to set up a central repository. Your full history resides in your working copy.
FooBarWidget 17y ago
I can't say for all distributed version control systems, but in case of git, it's extremely easy to setup a new repository. Create a new directory, type 'git init', and you're good to go. This compared to Subversion's insistence to setup a repo directory elsewhere and then checking that out. I save about 3 minutes (including time to ssh to a remote server to create the repository), but those 3 minutes feel very painful so I didn't create repositories until I've written a fair amount of code. Now I create a repository almost from the start. Branching and merging is very useful even for single developers. It's not the number of developers, it's the size of the project. For larger projects I'll want to branch often to experiment with things. I can delete the branch after I'm done with the experiment. As for Windows support: I've heard that Msys-Git is in a very good shape today. I haven't used it myself though.