4 ms·

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so peop

by dijit 3y ago

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free to distro maintainers C) People keep coming up with different paradigms that attempt to solve problems monorepos solve inherently.

maccard 3y ago
Perforce doesn't need to because nothing really threatens it. They're not interested in becoming more known, because they don't need to be. I can't imagine Debian of all projects using a proprietary VCS though.
xprn 3y ago
I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror). There might very well be some context I’m missing, but that’s what I understand from that side at least.
- fragmede 3y ago
  they (well, Linus) invented git for their purposes, and not the other way around. They use git and mailing lists because that's how they work, and that's how they worked before git existed. git was built for them.
- jorvi 3y ago
  Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.
  - skydhash 3y ago
    Sometimes friction is necessary for quality. More often than not, I’ve seen github repos where issue is treated as a project manager and there are lots of drive-by PRs.
  - zer00eyz 3y ago
    I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo Git is a tool built for a project of the kernels scope, scale and organization. Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests). Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.
    - jorvi 3y ago
      Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. People see a bit of code they want to improve, they improve it, and then instead of just opening a PR (and perhaps iterating on it), now they have to learn a weird ancient e-mail workflow and will probably get chewed out for messing it up. No one is saying to take away mail-in patches but it is positively archaic.
      - zer00eyz 3y ago
        >> Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. Is it friction? Or is it a filter? You might remember being a kid and there was the sign in front of the ride that said "you must be at least this high to ride".... The kernel dev process isnt for casuals. It's designed that way. There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests. You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons).... Your going to look at git in a very different way and many of githubs features are gonna feel on par with linkedin adding twitch style videos and zoom adding mail features...
codesnik 3y ago
from what I've heard, git become much friendlier with monorepos in recent years because of microsoft involvement. Windows repo, pretty sizeable, is now using git, and it supposedly works even without strange things like vfs for git.
- redleader55 3y ago
  It's not only Windows that uses Git at Microsoft, but Sharepoint and Office (which includes the on-prem version of SharePoint). In terms of repo size Windows and Office are similar. I was part of the team that migrated Sharepoint from a Perforce clone to Git and helped build the tooling to allow Office to move as well. VFS for Git [1] and Scalar [2] are really good pieces of software. [1] - https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit [2] - https://github.com/microsoft/scalar https://github.com/microsoft/scalar
  - silverwind 3y ago
    I hope one of these "large file/many files" extensions becomes part of git core eventually. They are too much of a hassle to deal with and many servers don't even support them.
4ad 3y ago
> Perforce isn't trying to gain adoption by giving its software for free to distro maintainers Perforce has been giving its software for free to OSS projects since forever. FreeBSD used to use Perforce, for example. OSS people and projects don't want Perforce, not the other way around.
- bluGill 3y ago
  Freebsd developers used perforce but the official repo was cvs and somehow the two synced.
wongarsu 3y ago
For better or for worse, Perforce seems to see itself mainly in the niche of having binary or media files in source control. They are busy promoting themselves in game dev, automotive, etc, where this is a common pain point. Maybe they should do more to highlight their strengths with regards to monorepos, but apparently their marketing hasn't identified that as a strength, or thinks it isn't a worthwhile market.
- Xeamek 3y ago
  Games I understand, but what makes automotive a place that uses a lot of binary files?
  - francocalvo 3y ago
    Probably tons of 3D models

by dijit 3y ago

maccard 3y ago

Perforce doesn't need to because nothing really threatens it. They're not interested in becoming more known, because they don't need to be. I can't imagine Debian of all projects using a proprietary VCS though.

xprn 3y ago

I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror). There might very well be some context I’m missing, but that’s what I understand from that side at least.

fragmede 3y ago
they (well, Linus) invented git for their purposes, and not the other way around. They use git and mailing lists because that's how they work, and that's how they worked before git existed. git was built for them.
jorvi 3y ago
Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.
- skydhash 3y ago
  Sometimes friction is necessary for quality. More often than not, I’ve seen github repos where issue is treated as a project manager and there are lots of drive-by PRs.
- zer00eyz 3y ago
  I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo Git is a tool built for a project of the kernels scope, scale and organization. Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests). Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.
  - jorvi 3y ago
    Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. People see a bit of code they want to improve, they improve it, and then instead of just opening a PR (and perhaps iterating on it), now they have to learn a weird ancient e-mail workflow and will probably get chewed out for messing it up. No one is saying to take away mail-in patches but it is positively archaic.
    - zer00eyz 3y ago
      >> Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. Is it friction? Or is it a filter? You might remember being a kid and there was the sign in front of the ride that said "you must be at least this high to ride".... The kernel dev process isnt for casuals. It's designed that way. There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests. You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons).... Your going to look at git in a very different way and many of githubs features are gonna feel on par with linkedin adding twitch style videos and zoom adding mail features...

codesnik 3y ago

from what I've heard, git become much friendlier with monorepos in recent years because of microsoft involvement. Windows repo, pretty sizeable, is now using git, and it supposedly works even without strange things like vfs for git.

redleader55 3y ago
It's not only Windows that uses Git at Microsoft, but Sharepoint and Office (which includes the on-prem version of SharePoint). In terms of repo size Windows and Office are similar. I was part of the team that migrated Sharepoint from a Perforce clone to Git and helped build the tooling to allow Office to move as well. VFS for Git [1] and Scalar [2] are really good pieces of software. [1] - https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit [2] - https://github.com/microsoft/scalar https://github.com/microsoft/scalar
- silverwind 3y ago
  I hope one of these "large file/many files" extensions becomes part of git core eventually. They are too much of a hassle to deal with and many servers don't even support them.

4ad 3y ago

> Perforce isn't trying to gain adoption by giving its software for free to distro maintainers Perforce has been giving its software for free to OSS projects since forever. FreeBSD used to use Perforce, for example. OSS people and projects don't want Perforce, not the other way around.

bluGill 3y ago
Freebsd developers used perforce but the official repo was cvs and somehow the two synced.

wongarsu 3y ago

For better or for worse, Perforce seems to see itself mainly in the niche of having binary or media files in source control. They are busy promoting themselves in game dev, automotive, etc, where this is a common pain point. Maybe they should do more to highlight their strengths with regards to monorepos, but apparently their marketing hasn't identified that as a strength, or thinks it isn't a worthwhile market.

Xeamek 3y ago
Games I understand, but what makes automotive a place that uses a lot of binary files?
- francocalvo 3y ago
  Probably tons of 3D models