221–230 of 270 posts
This is funny, I stopped reading when it started talking about how engineer x will never touch section y of the code. Ok then put them in separate repos
It took me a while to find out what Canva actually does, but from https://www.canva.com it appears they are an online design / collab tool. To be fair, that could mean a _lot_ of functionality and code providing a rich, SPA, JS heavy experience. Modern JS frameworks aren't exactly known for being concise. But still, 60 million lines of code and half a million files is a sure sign that someone said at one point "sure,…
> Didn't someone on the team say "hey, it takes 10 seconds to run git status, can we move this junk out and do this another way??" Why do you assume they didn't? Just because they arrived at a different conclusion than you that doesn't mean they didn't thought about it. I might very well mean you did not considered the tradeoffs they had to take into account, mainly because you're out of the loop.
I appreciate this post. It's nice to see that there are other teams that feel some of the pain points of git, (and unsurprising that most of the responses are "you're holding it wrong"). The fact is that git doesn't scale to _very large_ repos, We've seen it time and time again, but there isn't really a great alternative. Perforce is.... Perforce (centralized, very expensive to license, branches are incredibly expens…
Just saying that Perforce "is Perforce" is pretty lazy. Perforce is great in my experience. It scales up to repo sizes you are unlikely to ever reach and has a UX that makes actual sense.
Perforce's branches are a disaster and should have been deprecated years ago and replaced with streams a decade ago. Branches are _incredibly_ slow, they're straight up copies, and they are pretty much isolated from each other. Streams are an improvement, but still are very primitive compared to git's branches - the change tracking across streams is poor, and the enforced hierarchy has too many escape hatches that can make a gigantic mess. Streams are loosely enforced with views which can't be customised per workspace, a major regression from branches. In practice, every team I've worked on has had a "convert merge to edit" style action to fix perforce's messed up idea of a merge. Stream switching is also dog slow (on my last project, it was quicker to delete the 150GB workspace, and re-sync than have perforce actually figure out what had changed).
Perforce is eye wateringly expensive, and very difficult to license - licenses are 4 figures per seat per year for medium sized businesses (and close to 4 figures for small companies), and maintaining a p4 server is genuine work. The hosted offerings of perforce (assembla only - https://get.assembla.com/pricing/) are very lackluster, and very limited (no triggers unless you pay the "contact us" pricing).
My experience in large teams was that running perforce at scale involves not using some/many of the features, and that actually keeping it running well pretty much requires an active support contract from perforce.
All that said, P4V is by far the best GUI client to any VCS, it _handles_ bianry files, and p4 sync's performance makes git clone feel like you're working on a 56k modem. It's just when you want to do anything other than submit or sync, the wheels fall off the track.
Did you consider VFS For Git and Scalar from Microsoft? What was the result? https://github.com/microsoft/VFSForGit https://github.com/microsoft/scalar
Earlier quoted context omitted.
Just saying that Perforce "is Perforce" is pretty lazy. Perforce is great in my experience. It scales up to repo sizes you are unlikely to ever reach and has a UX that makes actual sense.
In my defence, I elaborated in parentheses immediately after saying it. It's _very_ centralised and online only. There's no concept of any local work/branches so all prototypes are checked in (or in my experience people manually shelve things and juggle shelves around). Perforce's branches are a disaster and should have been deprecated years ago and replaced with streams a decade ago. Branches are _incredibly_ slow,…
Hey everyone, author here, the article is a bit misleading in that .xlf files aren't really generated files, they're created through our translation pipeline by real humans. I considered them generated in the sense that they're not directly worked on by engineers who have to deal with them in the repository. The content of these translation files are snapshot in time aligned with the text in our product so simply rem…
Can't those xlf files be stored in a separate repo or in an object storage and let the build system fetch them from there?
Earlier quoted context omitted.
Canva gives users without design tools expertise the ability to make fairly polished looking graphics with a super easy and intuitive interface. (As a designer, I can assure you that polished looking is not the same thing as designed.) It’s a very popular service, so they’re dealing with huge scale. Intuitive interfaces often come with complex mechanisms and lots of assets, and they have clients on every major mobile…
Don't rely on this anecdotal heuristic. Have a look at some enterprises. My experience: "How to solve scaling issues?" - "Automation? No, another team." ;)
Earlier quoted context omitted.
Ugh The price of letting less experienced people "go crazy" in the repo
Npm didn't support lockfiles until version 5, released in 2017, Yarn had them at launch in 2016. Before that committing node_modules was often used as a form of vendoring, to get reproducible builds. If a new project these days commits node_modules to git, it's likely a mistake, but for legacy projects started before 2017 it was the lesser of two evils. Edit: spelling.
Prior to lock files (and potentially after, as checked-in files are beyond trivial to modify and review and that can be worthwhile) committing dependencies in some form was basically the only reasonable way to have reproducible builds, unless you wanted to build your own package manager / lock file implementation.
Which is what Yarn did.
Earlier quoted context omitted.
Canva gives users without design tools expertise the ability to make fairly polished looking graphics with a super easy and intuitive interface. (As a designer, I can assure you that polished looking is not the same thing as designed.) It’s a very popular service, so they’re dealing with huge scale. Intuitive interfaces often come with complex mechanisms and lots of assets, and they have clients on every major mobile…
They have obviously invested a lot over time into streamlining their build process: so much so that they're putting an article about it. All of the problems they are having are basically due to their use of a monorepo: they do explain that they made the decision early, but I wonder what are the advantages over multiple repos they are seeing that it was worth it all this trouble?
I get a headache imagining everything Google in a monorepo. So how do you reconcile this single GIT repository approach with Infoworld's "The case against monorepos"? [1]: Reason #1. Monorepos go against single-team ownership principles Reason #2. Monorepos encourage bad practices involving massive refactoring Reason #3: Small repositories are better than large ones [1] https://www.infoworld.com/article/3638860/the-c…
> In Google’s case, more than 45,000 changes are made to its monorepo every day. This code management becomes an exponential problem in overhead as the number of developers of an application grows, and the number of components within the application expands.
Speaking from experience, the overhead of code management is far less at Google than any other place I've worked at, even on projects with just a couple hundred lines of code. If this author is imagining a monorepo means each engineer having to constantly check out terabytes of code to make any change and race with other developers to merge to HEAD, they don't really understand the landscape well enough to write an article criticizing monorepos (which certainly have real cons, particularly with the source control tools that are available to most companies).
Of course, you need actual tooling and infrastructure for that beyond what git offers.