Hacker News Reader

Comment by 2d8a875f-39a2-4 | Hacker News Reader

Always nice to read a new retelling of this old story.

TFA throws some shade at how "a single get of the office repo took some hours" then elides the fact that such an operation was practically impossible to do on git at all without creating a new file system (VFS). Perforce let users check out just the parts of a repo that they needed, so I assume most SD users did that instead of getting every app in the Office suite every time. VFS basically closes that gap on git ("VFS for Git only downloads objects as they are needed").

Perforce/SD were great for the time and for the centralised VCS use case, but the world has moved on I guess.

View on HN

Some companies have developed their own technology like VFS for use with Perforce, so you can check out the entire suite of applications but only pull the files when you try to access them in a specific way. This is a lot more important in game development where massive source binary assets are stored along side text files.

It uses the same technology that's built into Windows that the remote drive programs (probably) use.

Personally I kind of still want some sort of server based VCS which can store your entire companies set of source without needing to keep the entire history locally when you check out something. But unfortunately git is still good enough to use on an ad-hoc basis between machines for me that I don't feel the need to set up a central server and CI/CD pipeline yet.

Also being able to stash, stage hunks, and interactively rebase commits are features that I like and work well with the way I work.

Doesn’t SVN let you check out and commit any folder or file at any depth of a project you choose? Maybe not the checkouts and commit, but that log history for a single subtree is something I miss from the SVN tooling.

Can you not achieve the log history on a subtree with `git log my/subfolder/`? Tools like TortoiseGit let you right click on a folder and view the log of changes to it.

Yes it can, but the point is that in a git repo you store the entire history locally, so whenever you clone a repo, you clone its history on at least one branch.

So when you have a repo that's hundreds of GB in size, the entire history can be massive.

You can indeed. The problem with this strategy is that now you need to maintain the list of directories that needs to be checked out to build each project. And unless this is automated somehow, the documentation will gradually diverge from reality.

My firm still uses perforce and I can't say anyone likes it at this point. You can almost see the light leaves the eyes of new hires when you tell them we don't use git like the rest of the world.

I cannot believe that new hires would be upset by the choice of version control software. They joined a new company after so many hoops and it's on them for having an open mind towards processes and tools in the new company.

If companies don't cater to the whims of the youth, they'd have to hire... old people

e-gad!

But those cost so much more!

But they are Analysts and know corporate speak and are really good at filling their schedules with meetings! They must be so busy doing very meaningful work!

I almost cried of happiness when we moved to git from SVN on my first job after being there for 6 months

They might not be upset on the first few weeks but after a month or so they will be familiar with the pain.

Oh a month is definitely enough time.

    > cried of happiness when we moved to git from SVN

You bring back some real memories with this phrase.

I recall moving from RCS and CVS and thinking: "Oh, this is a real improvement." (Forgive me; I was young.)

Then, I moved from CVS to SVN and thought: "This is revolutionary. I can rename and merge." (Again, please withhold throwing your tomatoes until the end of the story!)

Later, projects grew large enough, that SVN became horrible because of how I/O worked on my PCs/networks (file by file, long before 1G network to developer PCs and horribly slow spinning disks).

The upgrade to Git was epic. Sure, the commands are weird and complex. More than 10 years later, I still need to lookup a command once a month, but it beats the pants off anything before. Hat tip to all the people (Hamano-san, et al) who have contributed to Git in the last 20 years. My life as a developer is so much better for it.

I never used CVS but I remember our internal joke about SVN is that SVN is like hotel California, you can branch but you can never leave [by merging the branch]

I worked with someone who was surprised the company didn’t use Bitbucket and Discord. They were unhappy about both.

Discord I get, at least from a community or network effect, but Bitbucket? I can’t figure out why anyone but a CTO looking to save a buck would prefer Bitbucket.

I cannot imagine many jobs use Discord over Slack/Teams unless they’re gaming related. This was not a gaming related job.

We use BitBucket where I work. Due to certain export regulations it's simpler for us to keep as many services as possible on-prem if they're going to contain any of our intellectual property, so BitBucket Server it is. There are other options of course, but all of the cloud solutions were off the table.

sorry for the tangent, how you deal with AI?

Why would you expect them to? It's really easy to live without AI.

nothing prevents them to run a gpu locally or on their own infra.

I was asking because I wonder what the enterprises that want to both use AI on their workflows like LLM's and have air-gap owned 100% data and pipelines are doing rn.

Feels like one of the few areas where to compete with big labs to me, might be wrong

Presumably they don't use it.

External AI are banned, local or otherwise on-prem models are allowed. We're currently experimenting with some kind of llama instance running on one of our servers, but I personally don't use it much.

But why not GitLab or GitHub’s on prem servers?

I wouldn't know, the choice was made years before I joined the company, and I haven't come across anyone who told me what considerations went in back then.

I actually quite like the interface of bitbucket. I think it's better, in a lot of ways, compared to gitlab and github.

What I hate about bitbucket is how stagnated it is.

I feel like I’ve got an open mind towards processes and tools; the problem with a company using anything other than Git at this point is that unless they have a good explanation for it, it’s not going to be an indicator that the company compared the relative merits of VCS systems and chose something other than Git - it’s going to be an indicator that the company doesn’t have the bandwidth or political will to modernize legacy processes.

maybe they're on bazel?

Well bazel is not a tool for version control.

damnit i was thinking jujutsu and got owned lol https://github.com/jj-vcs/jj

Yeah but as a new hire, one doesn't yet know whether there is a good explanation for using a non-git tool. It takes time to figure that out.

A legacy tool might be bad, or it might be very good but just unpopular. A company that devotes political will to modernize for the sake of modernizing is the kind of craziness we get in the JS ecosystem.

I mean if I'm a potential new hire, I'm just going to ask why they're not using Git, and give them the opportunity to give me a good explanation before I start there.

I'm with you on the JS ecosystem - I work on crufty .NET desktop apps - but you couldn't pay me to work on my crufty .NET apps using SVN.

A craftsman appreciates good tools.

Is git a good tool then? Not necessarily. Some still think hg is better. Others think newer tools like jj are even better while being git compatible.

Perforce is sufficiently idiosyncratic that it's kinda annoying even when you remember the likes of SVN. Coming to it from Git is a whole world of pain.

The problem is that you come to a prestigious place like Microsoft and end up using horrible outdated software.

Credit where credit is due at my time at Excel we did improve things a lot (migration from Script# to TypeScript, migration from SourceDepot to git, shorter dev loop and better tooling etc) and a large chunk of development time was spent on developer tooling/happiness.

But it does suck to have to go to one of the old places and use sourcedepot and `osubmit` the "make a change" tool and then go over 16 popups in the "happy path" to submit your patch for review (also done in a weird windows gui review tool)

Git was quite the improvement :D

What's Script#?

C# like language compiled to Javascript.

> I cannot believe that new hires would be upset by the choice of version control software.

I can, if the version control software is just not up to standards.

I absolutely didn’t mind using mercurial/hg, even though I literally haven’t touched it until that point and knew nothing about it, because it is actually pretty good. I like it more than git now.

Git is a decent option that most people would be familiar with, cannot be upset about it either.

On another hand, Source Depot sucked badly, it felt like I had to fight against it the entire time. I wasn’t upset because it was unfamiliar to me. In fact, the more familiar I got with it, the more I disliked it.

You missed the point. The point is, a new hire being asked to use a new version control software likely doesn't know whether the tool is more like hg or more like source depot. It takes times to figure out that. So they need to reserve judgement.

Not what I got out of that comment, but I fully agree with your take on new hires not being able to tell whether an unfamiliar version control piece of software is good or bad until they get at least somewhat familiar with it.

Yeah it's an issue for new devs for sure. TFA even makes the point, "A lot of people felt refreshed by having better transferable skills to the industry. Our onboarding times were slashed by half".

Interesting to hear it was so much of a problem in terms of onboarding time. Maybe Source Depot was particularly weird, and/or MS were using it in a way that made things particularly complicated? Perforce has never felt especially difficult to use to me, and programmers never seem to have any difficulty with it. Artists and designers seem to pick it up quite quickly too. (By and large, in contrast to programmers, they are less in the habit of putting up with the git style of shit.)

> Interesting to hear it was so much of a problem in terms of onboarding time. Maybe Source Depot was particularly weird, and/or MS were using it in a way that made things particularly complicated?

It was not. It was literally a fork of perforce with executable renamed to sd.exe from p4. Command line was pretty much identical.

    > git style of shit

I don't understand this phrase. Can you explain more?

It's a fairly typical Unix tool, but: worse! It's got a rather cryptic and unhelpful command line UI that's often fiddly to use, rather requires you to understand its internals in order to work with it, and has lots of perplexing failure modes. There are GUIs for it, which do help, but people moan at you if you use them, and/because they're often opinionated and oriented towards some specific workflow or other. And they don't really stop it being fiddly to use, you still need to bear in mind how it works internally to use it, and the perplexing failure modes remain.

It's a generalisation, but, by and large, artists and designers don't enjoy using these sorts of tools. Also, they are more likely to be working with unmergeable files, something that git isn't really designed to work with.

(Programmers often don't like these sorts of tools either, but - again, a generalisation - they're harder to avoid if you're a programmer, so the average one is typically a bit more practised at putting up with this crap.)

In 2025, source code version control is incredibly complex. Hell, it was already complex 15 years ago, but the tools were probably worse! Have you ever seen the full manual for GCC/Clang? It is nuts. FFmpeg is legendary hard to use from the command line (no hate on Fabrice Bellard -- you still the man). Same for ImageMagick. I don't fault Git for it. If you want fine-grained control over every single possible action... well, you will wind up with a command line tool with an insane number of options.

Can't say anything about perforce as I've never used it, but I'd give my left nut to get Google's Piper instead of git at work :)

I concur. I miss citc & fig.

Piper's syntax is Perforce syntax.

I moved to Google from Microsoft and back when employee orientation involved going to Mountain View and going into labs to learn the basics, it was amusing to see fresh college hires confused at not-git while I sat down and said "It's Source Depot, I know this!"[1]

[1] https://www.youtube.com/watch?v=dFUlAQZB9Ng

VFS does not replace Perforce. Most AAA game companies still use Perforce. In particular, they need locks on assets so two people don't edit them at the same time and have an unmergable change and wasted time as one artist has to throw their work away

I'm a bit surprised git doesn't offer a way to checkout only specific parts of the git tree to be honest. It seems like it'd be pretty easy to graft on with an intermediate service that understands object files, etc.

It's existed for a while. Partial clones and LFS.

https://git-scm.com/docs/partial-clone

Thanks!

Reply on news.ycombinator.com