11 ms·

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

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.

theonewolf 11y ago
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.
- baconner 11y ago
  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.
JoshTriplett 11y ago
> 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?
- sytse 11y ago
  I would love to know as well. We offer GitLab Enterprise Edition so our naming already is compatible.
  - baconner 11y ago
    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.
- baconner 11y ago
  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!"

theonewolf 11y ago

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.

baconner 11y ago
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.

JoshTriplett 11y ago

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

sytse 11y ago
I would love to know as well. We offer GitLab Enterprise Edition so our naming already is compatible.
- baconner 11y ago
  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.
baconner 11y ago
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!"