Perforce introduces GitSwarm • Hacker News Board

Re: Perforce introduces GitSwarm

#31

Post by cynoclast » Tue, Oct 06, 2015, 9:36 PM UTC

sytse wrote: post #26

vvanders wrote: post #13

Earlier quoted context omitted.

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.

Re: Perforce introduces GitSwarm

#32

Post by mayoff » Tue, Oct 06, 2015, 9:47 PM UTC

cynoclast wrote: post #31

sytse wrote: post #26

Earlier quoted context omitted.

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.

Re: Perforce introduces GitSwarm

#33

Post by sytse » Tue, Oct 06, 2015, 9:47 PM UTC

cynoclast wrote: post #31

sytse wrote: post #26

Earlier quoted context omitted.

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.

I think it makes sense if it doesn't degrade performance, especially in game companies.

Re: Perforce introduces GitSwarm

#34

Post by mataway » Wed, Oct 07, 2015, 6:44 AM UTC

mayoff wrote: post #32

cynoclast wrote: post #31

Earlier quoted context omitted.

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.

Re: Perforce introduces GitSwarm

#35

Post by mataway » Wed, Oct 07, 2015, 6:52 AM UTC

mixologic wrote: post #23

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

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.

Re: Perforce introduces GitSwarm

#36

Post by baconner » Wed, Oct 07, 2015, 11:54 PM UTC

JoshTriplett wrote: post #18

baconner wrote: post #6

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 the…

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

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

Re: Perforce introduces GitSwarm

#37

Post by baconner » Wed, Oct 07, 2015, 11:59 PM UTC

sytse wrote: post #27

JoshTriplett wrote: post #18

Earlier quoted context omitted.

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