4 ms·

That would be nice, but handling of large binaries would be killer as well.

• jordigh 12y ago
  Barring some amazing breakthrough in data compression to the tune of P=NP, I just don't see how this problem could possibly be solved within the constraints of the "D" in "DVCS". The best thing we have now is to centralise large binaries and to use specialised binary-diffing tools for handling their changes. As discussed in Lobsters[1], that's more or less how Facebook has handled this particular problem[2]. [1] https://lobste.rs/s/tekiod/unorthodocs_abandon_your_dvcs_and_return_to_sanity https://lobste.rs/s/tekiod/unorthodocs_abandon_your_dvcs_and... [2] http://mercurial.selenic.com/wiki/ScaleMercurial#Concern:_Large_files http://mercurial.selenic.com/wiki/ScaleMercurial#Concern:_La...
  • FeloniousHam 12y ago
    Does git-annex[1] solve the large file problem? I know Gitlab suggested it as a solution. [1] https://git-annex.branchable.com/ https://git-annex.branchable.com/
    • jordigh 12y ago
      It does not solve the large file problem. It only changes the problem parameters so that a solution exists, by breaking the "D" in "DVCS". Its interface is kind of ugly, though. I don't know if gitlab gave it a better interface. The corresponding extension in Mercurial is largefiles, in case you still think there is room in the world for a DVCS other than git.
      • FeloniousHam 12y ago
        I'm pretty agnostic regarding scm, so long as I have lightweight branching and lots of tooling built with love. I only use the basic functionality in git (eg. no submodules, central master repo), so I wouldn't notice the difference between Mercurial, Bazaar, etc and git. Git may not be the best, but (probably because of Github) it is the winner in this generation.