3 ms·

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 u

• 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 :/
          • compay 17y ago
            Awesome, it'll be interesting to see the results. Make sure you do git repack -a -d -f --window=100 --depth=100 after converting from svn to git. Otherwise you'll have a lot of artifacts from the conversion lying around and the git repo will be HUGE. (taken from http://marc.info/?l=git&m=120734745806416 http://marc.info/?l=git&m=120734745806416)
  • 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]