Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).
Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.
check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.
git is so agnostic about all this stuff that you can even merge completely disparate, unrelated repositories (for example, my own primary "job" repository, and the linux kernel) into the same on-disk structure. Of course, doing so is useless because none of the commits from one repo has any relevance to the other. But because the commits are identified by true GUIDs, there are no collisions, and both sets of commits can happily exist in a single repo.
It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).
I found the ability to merge unrelated repositories very useful when collecting various bits of work I did separately and combining it into a single library.
Oh sorry, yeah, didn't use the right term, meant commit... Still, conceptually in terms of source control, think it's the right term (meaning the process of having your code changes added into the main repo).
... and btw, haven't thought about git in awhile, and am reviewing its concepts. It does really have some nice features - always used to think the staging area was an unused feature (and at least for me, it kind of is), but local branches are super useful, and it seems like all that focus on git being a distributed vcs allows (and requires) a dev to work more locally first in very flexible ways. This is really, really nice. Still not sure all the complexity is worth it...
Know this has been said countless times, but some abstraction layer on top of git (that is actually apart of git itself so that it becomes standard) would have been really nice. Understandably, since git started its life in use by sharp linux-devs, usability probably wasn't at the forefront, but yeah, how many countless hours worldwide would have been saved if git was easier to use? (the dreaded botched friday-night commit and update)
Funny because `git pull` is an abstraction like you talk about. It's a `git fetch` followed by a `git rebase`. Staging or `stashing`, it's all just leaves on the merkle tree. The concept of time/branches/doesn't exist. Only previous hash, current hash. It's simple and people have ADDED complexity to make sense of it (coming from other VCS').
True, the pull command is simple. But it's really the pushing and merging that cause the problems.
And, yeah, don't know if i'd call it simple in the way you're using the word. It's simple in that the tool is very "RISC" in nature instead of CISC, doing smaller simple operations instead of larger more complex ones (except for a few exceptions like pull). But for procedures like pushing your code, it's complex. You have to do a lot of things yourself that other VCS take care of. As you probably are aware of, you need to make sure you do things in the correct order, because the tool won't help you if you make a mistake. Don't think something like source control should be this way (especially when other VCS's don't require this amount of thought).
My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”.
You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.
It's hardly the same thing at this point. For instance you could say Nginx is API-compatible with Apache, and yes that is correct (Maybe? Let's not split hairs here). But to go as far as saying Apache is state of the art and link to Apache's homepage (like throw2ih020 did) is just like.... no.
I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.
While I agree with you, not at Google anymore, I do not consider them the top 3 engine providers that I am referring to in my post. No no, Unreal/Unity/Red/EA/SC it’s all perforce.
Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).
Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.
check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.
Delta patches become effortless
> It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.
If everyone uses it wrong, it was designed wrong. See Q-tips.
git is so agnostic about all this stuff that you can even merge completely disparate, unrelated repositories (for example, my own primary "job" repository, and the linux kernel) into the same on-disk structure. Of course, doing so is useless because none of the commits from one repo has any relevance to the other. But because the commits are identified by true GUIDs, there are no collisions, and both sets of commits can happily exist in a single repo.
It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).
I found the ability to merge unrelated repositories very useful when collecting various bits of work I did separately and combining it into a single library.
Oh sorry, yeah, didn't use the right term, meant commit... Still, conceptually in terms of source control, think it's the right term (meaning the process of having your code changes added into the main repo).
... and btw, haven't thought about git in awhile, and am reviewing its concepts. It does really have some nice features - always used to think the staging area was an unused feature (and at least for me, it kind of is), but local branches are super useful, and it seems like all that focus on git being a distributed vcs allows (and requires) a dev to work more locally first in very flexible ways. This is really, really nice. Still not sure all the complexity is worth it...
Know this has been said countless times, but some abstraction layer on top of git (that is actually apart of git itself so that it becomes standard) would have been really nice. Understandably, since git started its life in use by sharp linux-devs, usability probably wasn't at the forefront, but yeah, how many countless hours worldwide would have been saved if git was easier to use? (the dreaded botched friday-night commit and update)
Funny because `git pull` is an abstraction like you talk about. It's a `git fetch` followed by a `git rebase`. Staging or `stashing`, it's all just leaves on the merkle tree. The concept of time/branches/doesn't exist. Only previous hash, current hash. It's simple and people have ADDED complexity to make sense of it (coming from other VCS').
True, the pull command is simple. But it's really the pushing and merging that cause the problems.
And, yeah, don't know if i'd call it simple in the way you're using the word. It's simple in that the tool is very "RISC" in nature instead of CISC, doing smaller simple operations instead of larger more complex ones (except for a few exceptions like pull). But for procedures like pushing your code, it's complex. You have to do a lot of things yourself that other VCS take care of. As you probably are aware of, you need to make sure you do things in the correct order, because the tool won't help you if you make a mistake. Don't think something like source control should be this way (especially when other VCS's don't require this amount of thought).
Just my two cents.
My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”.
You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.
Yeah, hopefully, someday someone will write a really good one that becomes universal used.
It's not even baked into Google anymore.
Technically correct, but Piper is API-compatible with Perforce, so while there's presumably no license fee it's still strongly there in spirit.
https://graphite.com/blog/google-perforce-to-piper-migration
It's hardly the same thing at this point. For instance you could say Nginx is API-compatible with Apache, and yes that is correct (Maybe? Let's not split hairs here). But to go as far as saying Apache is state of the art and link to Apache's homepage (like throw2ih020 did) is just like.... no.
I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.
Is Google a big 3 media/entertainment studio?
While I agree with you, not at Google anymore, I do not consider them the top 3 engine providers that I am referring to in my post. No no, Unreal/Unity/Red/EA/SC it’s all perforce.
Ahhhh. Okay. I didn't realize you meant game studios. Wasn't familiar with that "big 3" term until now. Thanks for clearing that up.
Tech in general, you’re spot on though.