3 ms·

SVN is also better at handling (large) repos with (large) binary files than GIT. So if you decide to store your scanned business documents in a version control

• SEJeff 6y ago
  Indeed. Subversion stores history on a per-file basis and not a per-project basis. This is one of the precious few areas where Subversion does best git.
  • adrianmsmith 6y ago
    > Subversion stores history on a per-file basis and not a per-project basis. I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”. Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
    • SEJeff 6y ago
      No, I mean in the on disk format, the history is stored per-file. This is why svn blame is massively faster than git blame, because git blame has to go through history for all files to find the right bits whereas svn does not. The svn file format vs the git pack format are very very different on-disk.
      • alblue 6y ago
        That only works when your SVN server is in the same computer as you; the fact that SVN has to reach out to get additional data for the history is what kills it. With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using. In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.