Perforce introduces GitSwarm | Hacker News Reader

Perforce introduces GitSwarm

perforce.com

35 pointswdding35 comments

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.

> 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?

Git blame will often get the guy who fixed a spelling mistake in a variable, not the guy before him who wrote the code.

To 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.

There is, try `git gui blame`.

I do, and it doesn't hold even 1 candela to P4's timeline. ;)

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.

“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.

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 it makes sense if it doesn't degrade performance, especially in game companies.

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.

Actually 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.

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?

I would love to know as well. We offer GitLab Enterprise Edition so our naming already is compatible.

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...

Anyway serious answer in parent.

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!"

Update: They do cite GitLab. Now I guess my confusion as a GitLab user is they don't sell me on what is new/differentiate their customized offering.

This product looks like a poorly rebranded GitLab.

Why don't they cite GitLab as the front-end web application/real workhorse here?

They do, "GitSwarm is where developer preferences meet enterprise needs. Based on the popular GitLab collaboration suite ..."

I see. I understand the problem they're solving now.

Bringing Git + more agile development flows into the Enterprise.

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".

Uh, really?

We recently heard that we were giving out links to GitLab's documentation instead of our own, (which we didn't have up on our website at the time.) We have since thrown them up here: http://www.perforce.com/perforce/doc.current/manuals/gitswar...

What got my attention was the "narrow cloning for greater security". Im really curious how they are managing to implement narrow cloning with git.

They make a git repo out of a subdirectory of the Perforce repo.

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.

too little too late

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.

Couldn't even finish watching the intro video because of annoying voice-over. I'm probably not the target audience.

I really don't get the value-add here? Everything looks like stock GitLab?

Can't see the video because they use flash. So enterprisey.

Reply on news.ycombinator.com