4 ms·

I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local driv

by to3m 14y ago

I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly) - As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system... The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.

lucisferre 14y ago
You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).
- plorkyeran 14y ago
  That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
- to3m 14y ago
  You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.
i386 14y ago
Shallow clones might be a partial answer to your first point. You can use the --depth X option on the Git command line to only fetch the last X revisions. This means the shallow clone can be much much smaller than the complete clone.

by to3m 14y ago

lucisferre 14y ago

You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).

plorkyeran 14y ago
That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
to3m 14y ago
You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.

i386 14y ago

Shallow clones might be a partial answer to your first point. You can use the --depth X option on the Git command line to only fetch the last X revisions. This means the shallow clone can be much much smaller than the complete clone.