Hacker News Reader

Comment by meibo | Hacker News Reader

Being deceptive about Git's shortcomings is going to raise eyebrows with anyone seriously evaluating your solution, which is already going to raise eyebrows because it's not free software.

Most studios will try to avoid locking themselves into another expensive, annoying VCS that they have no control over. There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out.

View on HN

> There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out.

There are? Like what?

Yes Please. I would switch my studio today if this existed.

Hi, why the switch? Purely cost? Or admin overhead?

Yes, to both. P4 itself is solid, but it's a very chatty protocol and is very latency sensitive. Running a master in the us, with clients in europe is painful for everyone involved. Replicas and edge servers come with other tradeoffs too.

As a developer, doing things like "I only want this subtree of the stream" is hard. Virtual streams exist, but they have a (non-negligible) overhead on the server. It has some quirks due to it being 30 years old which make it... interesting, to work with sometimes.

Agreed. It's also expensive, and support has been lacking. We'd much prefer something we could maintain and fix ourselves.

Of all the complaints I have about p4, support is actually one I'm ok with. They've pretty consistently helped me fix issues over the years (plenty of which are bugs on their side that they have fixed after I raised it). Their sla is good, and their engineers are usually good at troubleshooting.

They are wildly, wildly expensive though.

That totally depends on where you put value. We're a fraction of other companies licenses for comparison. Also, we have new pricing for our new Helix Core Cloud SaaS product!

Yeah. New pricing, but not cheaper. Don't get me wrong. It's a fine price to pay for a studio going strong. But there is no way I can use it for starting my side-project indie game.

> there is no way I can use it for starting my side-project indie game.

I am not a defender of P4, but for some reason I'm defending them in this thread. It's free for < 5 people [0] if you want a side-project indie game.

[0] https://www.perforce.com/products/helix-core/free-version-co...

Yeah, but afaict, not their new cloud service.

Lightweight branching is coming "soon" and will help this exact issue. Contact me for more info.

I've been attempting this but have paused the efforts due to what seems like lack of interest -- giving me an indication that the problem is not that big of a deal.[0][1]

If anyone is interested in my resuming them, let me know at contact at weedonandscott dot com

[0] https://www.reddit.com/r/vfx/comments/11s08ne/your_opinion_o...

[1] https://www.reddit.com/r/gamedev/comments/11s5haf/what_do_yo...

I don't read the replies here as a lack of interest, more as a lack of interest in the solution you've come up with.

I don't disagree, but usually when a solution doesn't fix a painful problem, people are almost disappointed after getting their hopes high. In those posts, the commenters give me the impression that they are mildly annoyed at best (or worst).

I can't speak for the VFX post, but I think the gamedev post shows the weaknesses of git in one line:

> Git does have problems, we’ve had processes fall over on projects, many times actually, but it’s always solvable.

Every team that I've worked on would replace that tool with someonthing more stable if it existed. It does for version control, and it's perfoce, which comes with a hefty license fee, and a _different_ set of problems.

The selling point of Pipetrack is the commutativity, but to echo the comments in those threads, I've never found myself wanting commutavity. In games I want a mainline branch, support for large assets, granular access controls, performant, shared global system, and a method to cleanly differentiate between wip changes and ready changes in a way that works with non-technical users, and won't be the highest individual line item per-user subscription we pay for. Unless the selling point of your tool fixes one or many of those problems, it's not going to help in games.

Honestly, I think we'd be better off on SVN than git most of the time, but the _tooling_ around git is far superior.

> Being deceptive about Git's shortcomings

Are they being deceptive? I'm not sure I see it.

Not deceptive but I would say they're being hand wavy.

The story about irrevocably losing data at least was not true (already admitted by the authors).

I think I would give them that one, they were only able to recover the data because they got lucky, not because the system was designed to not destroy data. I would go even further coming from my infra background, even if you don't truly lose production data, if you have to reach into your DR backups that's a failing of the systems in place that come before it.

I'd say git is deceptive: "checkout" doesn't mean "delete my stuff" any more than checkout a book from the library means throw it in a wood chipper.

Reply on news.ycombinator.com