4 ms·

His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to conver

His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert. How likely is it that Linus will add better support for binary files from an outside project or do we just have to use the forked git?

nollidge 17y ago
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?
jrockway 17y ago
His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert. I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.) (Yes, OK, I have a favicon.ico in some of my repositories. This has not detracted from the "git experience".)
- weaksauce 17y ago
  Of course it's not a backup solution. That's what timemachine, superduper, mozy are for. Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" To each their own though. A version control system is such that it can handle versions of the project and not just versions of the source code. FWIW: I keep whatever files in the project I have uncompressed in git and it hasn't killed my HD space yet.
  - jrockway 17y ago
    Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" Of course, if Photoshop were Free Software, then you could just make the undo history and the git repository the same thing. That would be the ideal situation.
    - weaksauce 17y ago

nollidge 17y ago

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?

jrockway 17y ago

His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert. I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.) (Yes, OK, I have a favicon.ico in some of my repositories. This has not detracted from the "git experience".)

weaksauce 17y ago
Of course it's not a backup solution. That's what timemachine, superduper, mozy are for. Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" To each their own though. A version control system is such that it can handle versions of the project and not just versions of the source code. FWIW: I keep whatever files in the project I have uncompressed in git and it hasn't killed my HD space yet.
- jrockway 17y ago
  Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" Of course, if Photoshop were Free Software, then you could just make the undo history and the git repository the same thing. That would be the ideal situation.
  - weaksauce 17y ago