3 ms·

Haven't used Git or Mercurial at all, so I'm wondering: How does DVCS suck at binary files currently? Does it just not support them or something?

weaksauce 17y ago
It's part of their nature. They store the complete history of the repository by default on your computer. Git does not pack the files by default. I am still figuring out all the innards of Git but I believe that it stores a new copy of the file each time it changes and then hardlinks the tree object to the new file. you can run a pack operation that will create deltas of the files but this is an additional step. Any Git gurus here please correct my understanding of how Git manages binary files.
schacon 17y ago
Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue. Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol. Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.
- gecko 17y ago
  "In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can." You cannot do this as of Git 1.6.6, according to the documentation, which states: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches." What newer version of Git is there?

weaksauce 17y ago

It's part of their nature. They store the complete history of the repository by default on your computer. Git does not pack the files by default. I am still figuring out all the innards of Git but I believe that it stores a new copy of the file each time it changes and then hardlinks the tree object to the new file. you can run a pack operation that will create deltas of the files but this is an additional step. Any Git gurus here please correct my understanding of how Git manages binary files.

schacon 17y ago

Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue. Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol. Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.

gecko 17y ago
"In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can." You cannot do this as of Git 1.6.6, according to the documentation, which states: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches." What newer version of Git is there?