6 ms·
What value does this add, other than perhaps supporting a proprietary build & deploy system already paid for built around Perforce??? (is the latter a feature,
by Roboprog 11y ago
What value does this add, other than perhaps supporting a proprietary build & deploy system already paid for built around Perforce??? (is the latter a feature, or a bug?)
Every commercial revision control system I have ever used (ClearCase; SourceSafe; MKS Source Integrity; Serena VM aka PVCS) has always been much more of a PITA than CVS / SVN / Git. So, yeah, I'm very skeptical.
- dahart 11y agoI had the same skeptical question in my head while reading the landing page / ad. But, I will say I super miss P4's 'timeline'. I haven't used Perforce tools for many years now, but last time I did it was way way easier & faster to figure out who wrote a line of code than it is in git today. And overall, the UI was much better then than any git based UI is today. So, it might be hard for them to explain to git users, but personally, I'm open to the possibility they have some value added.
- Tuna-Fish 11y ago> it was way way easier & faster to figure out who wrote a line of code than it is in git today. Don't you have git blame integration in your editor?
- brianwawok 11y agoGit blame will often get the guy who fixed a spelling mistake in a variable, not the guy before him who wrote the code.
- kazinator 11y agoTo continue digging previous history: git blame <sha>^ -- file.c Where <sha> is the hash of the commit where the spelling mistake was made, pulled from the original blame from HEAD. Though I don't use such stuff, I would be surprised if there wasn't IDE support to make this "deeper dig" more of a point and click operation.
- vetrom 11y agoThere is, try `git gui blame`.
- dahart 11y agoI do, and it doesn't hold even 1 candela to P4's timeline. ;)
- vvanders 11y agoLooks like it has integration with an existing P4 server. There's quite a few teams(GameDev+Movies) who use P4 for scale+locking for binary assets where exposing a git endpoint would be useful from a tooling perspective.
- sytse 11y agoThis is spot on. Perforce can handle enormous monorepos with all the code and binary assets of an organization. For those we're very glad that this gives them the option to use our GitLab.
- cynoclast 11y agoYou're not wrong, but storing binaries in a VCS system seems a perversion of the concept to me. I don't miss working for a company that stored binaries in perforce. It's a symptom of bigger problems.
- mayoff 11y ago“Binary assets” here doesn't mean compiler output. It means graphics, audio, and other files in non-text formats that you edit with specialized tools.
- mataway 11y agoExactly. For game companies in particular, the code and the digital assets are dependent on each other. It's a bad day when you run your code against models that are missing bones the code expects.
- sytse 11y agoI think it makes sense if it doesn't degrade performance, especially in game companies.
- baconner 11y agoI think you're basically right here, but many companies are going to have a huge amount of code, builds, work history, etc wrapped up in these systems. So making a big bang move off to a different system can be time consuming, costly, etc. I get why you might want to bridge the gap here or even stick with the other aspects of these systems while abandoning the vcs portion for git in that circumstance. Also sounds like gitswarm let's you integrate code back into a broader perforce codebase so you could see how in a huge org with hundreds of devs you could move your groups code into a git workflow without having to turn the whole battleship. So I think this solves some problems pragmatically for big teams already entrenched in perforce, but its not ideal.
- solomatov 11y agoActually IMO, their product is much better than CVS and SVN. Much better UI, performance, etc. However git is a classical disrupting innovation which is destroying their business.
- cynoclast 11y agoNailed it. You know what Perforce is? An overcomplicated, shittier version of SVN that's harder to use, and uses a bunch of the wrong words to describe thing so as to separate it from SVN and boost vendor lock-in. Git is hard to understand for someone used to CVS/SVN, but it's better than both in the and, and completely free.