I am learning the two source code control systems and discovered that their branching strategies are very different.
That Perforce copies all of its original file to the new branch, although it does adapt some tricks (e.g. lazy copy, “p4 -v”) to prevent space grow, but eventually it will consume more space and leave more meta data. Instead, that in GIT, branching is basically moving of pointers around. I am wondering why Perforce cannot adapt that same approach? Is that because it comes with the burden of storing snapshots(as in git) instead of file difference(as in Perforce)?
Also, why GIT stores the snapshots of files instead of the difference? Is there any necessity of doing so? Does it mean that in general case GIT code repository will be larger than that of Perforce? If the same thing are to be stored in both systems? Will committing takes longer for GIT?
Git actually does store deltas as well. These are called pack files. If you changed a file 100 times slightly, it is not going to keep 100 slightly different objects. (more here: http://git-scm.com/book/en/Git-Internals-Packfiles)
Snapshots are the absolute truth that’s why git stores history like that. It takes the simple approach of not assuming how and why files changed a certain way. It’s vision is to have the tooling above analyze history to give you information such as “this file was renamed at this point”.
If that was part of history, you would have to rewrite it all if your threshold for what constitutes a rename w/ a small change vs. a delete and a create changed. Simple is better. The fact that this was designed on linux to track linux source code, it follows similar philosophy of that platform.