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.
I 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.
Looks 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.
This 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.
You'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.
Exactly. 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.
I 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.
Nailed 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.
First tfs, now perforce. The prevalence of git is clearly putting a lot of pressure on "enterprise" source control systems. It makes a lot of sense to just co-opt it and pull it into the rest of their ecosystem.
At my org we've been trying to move towards an oss style pull request flow for tools and infrastructure projects but meeting a little resistance because "not enterprise." Getting that workflow into one of these systems really unsticks the problem.
Oh I see, so this might be an "Enterprise in" and that's the "key feature." Not that I should expect a lot more on top of Git + GitLab that isn't already there.
I think that's about right. Heck we are actually running gitlab already for a limited set of projects and I could see how I could sell this easier.
Also don't discount how much might be bound up in a system like perforce already so this let's devs get git workflow that they want without being totally separate from all the other codebases.
> At my org we've been trying to move towards an oss style pull request flow for tools and infrastructure projects but meeting a little resistance because "not enterprise."
I'd love to know what 'because "not enterprise"' means in your case. Resistance to a model without exclusive locks? Resistance to a non-centralized model? Support questions?
Ha well you got the name right, yes. Sadly there's a bit more to it to sell to an enterprise software consumer - here just fill out this 30 page rfp...
Maybe it would be more correct to say - mostly because its not from a long lived company and also a dash of open source fear. One of the aspects of enterprise software is that customers want to rely on it over the long term with low fear that it's going to disappear or break. Enterprise software customers are like nervous foals - you don't want to spook them!
It's really the same reason that big enterprises have ended up using source control destruction systems like visual source safe instead of basically any free source control. We used vss for a huge codebase (hundreds of devs) and no amount of dev complaining got us to move off of it. It want until there was a major loss of source issue and then we somehow made the decision to move to tfs if you can believe that. "Well... Msdn plus it'll be around for the long term you know. And look there are branches! Omg!"
Lets take it as a given that you are excited about becoming a poweruser of the perforce ecosystem (hey, if my complany chose this tool, the least I can do is understand it very, very well), documentation resources are lacking I.M.O.
very few up to date third party books, the video tutorials hang while you watch them, the documentation instructs you to press buttons that simply aren't there in the GUI. with no alternates give.
we paid for professional training and the answer given in the meeting was "experiment and see how it's working".
Community manager from Perforce here. Basically it's what Sytse said; we do bi-directional replication between a p4 server and a git repo. You can carve off any hunk of a p4 server and surface it as a git repo. What we've seen some people do is push a monorepo into a p4 server and then carve off smaller repos that are more tightly scoped. Everything still goes back into p4 though, so you can still get the benefits of a mono repo.
The neat thing is that multiple git repos can consume the same pieces of a p4 server making code sharing between git repos seamless.
36 comments
[ 3.6 ms ] story [ 88.4 ms ] threadEvery 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.
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.
Don't you have git blame integration in your editor?
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.
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.
However git is a classical disrupting innovation which is destroying their business.
Git is hard to understand for someone used to CVS/SVN, but it's better than both in the and, and completely free.
This product looks like a poorly rebranded GitLab.
Why don't they cite GitLab as the front-end web application/real workhorse here?
Bringing Git + more agile development flows into the Enterprise.
But I do feel sorry for the telesales guy who is forced to call me every 6 months to see if I want to use Perforce.
At my org we've been trying to move towards an oss style pull request flow for tools and infrastructure projects but meeting a little resistance because "not enterprise." Getting that workflow into one of these systems really unsticks the problem.
Also don't discount how much might be bound up in a system like perforce already so this let's devs get git workflow that they want without being totally separate from all the other codebases.
I'd love to know what 'because "not enterprise"' means in your case. Resistance to a model without exclusive locks? Resistance to a non-centralized model? Support questions?
Anyway serious answer in parent.
It's really the same reason that big enterprises have ended up using source control destruction systems like visual source safe instead of basically any free source control. We used vss for a huge codebase (hundreds of devs) and no amount of dev complaining got us to move off of it. It want until there was a major loss of source issue and then we somehow made the decision to move to tfs if you can believe that. "Well... Msdn plus it'll be around for the long term you know. And look there are branches! Omg!"
very few up to date third party books, the video tutorials hang while you watch them, the documentation instructs you to press buttons that simply aren't there in the GUI. with no alternates give.
we paid for professional training and the answer given in the meeting was "experiment and see how it's working".
Uh, really?
The neat thing is that multiple git repos can consume the same pieces of a p4 server making code sharing between git repos seamless.