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.
This is, I think, very common with stuff like browsers, where you have artifact checkouts that basically include built stuff since otherwise you're sitting there compiling forever all the time.
Stuff like Bazel in theory helps with this, but tools that help with this are either super idiosyncratic about how they work (meaning hard to adopt) or outright don't work.
I mean personally I would find that pretty annoying and unclean but I like DAGs.
The likelihood of a 2000 employee software company simply not considering that they could streamline their build process is pretty slim.
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 would encourage you to do some research and keep an open mind.
The question is specifically about their usecase, since not everybody would hit the same bottlenecks as they did with git monorepos.
Iow, have they stopped and thought whether it's still worth it (eg how often do their engineers make use of the monorepo benefits like cross-project refactorings)?
By the numbers you mention, 70% of the files make a ratio of code files to translation files 1-3, so unless you only support 3-5 languages, it's definitely not one XLIFF file per source file, so I wonder at what granularity it is?
(My experience is mostly with localizations using GNU gettext tools, and you usually do a small-finite-number of PO files per project per language, where that small-finite number is exactly one for like 99% of projects)
Good job managing all that regardless of the approach :)
The only exception is our generated OpenAPI spec, because we want people to be explicit about modifying the API, and have a CI task that verifies that the API and OpenAPI spec match.
Something like: "This change will result in the following new API endpoints: ... do you wish to continue?"
What does it compare against though? Need to add more state to the CI? We kinda like the interface be part of the version control and having an audit chain that's part of the code.
Though even without that, I'm not sure how it'll even mechanically work.
It is gone now.
Docker is a congregation of technologies held together with duct tape and glue.
Eg. permissions handling is completely different on Macs with Docker Desktop from the Linux dockerd stuff: on Macs, it automatically translates user ownership for any "mounted" local storage (like your code repository), whereas on Linux user IDs and host system permissions are preserved. Have some developers use Macs and others use Linux, and attempt to do proper permissions setup (otherwise known as "don't run as root"), and you are looking for some fun debugging sessions.
No, it's not. What a wild conclusion to reach from the example you gave.
The price of letting less experienced people "go crazy" in the repo
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.
> it takes 10 seconds to run git status
For many processes I think SVN is (and has been for many many years) been an absolutely fine method of version control
> didn't find it offered any features that would significantly improve our process, but found 1000 more ways to shoot ourselves in the foot
I really like git for the cheap branching, which encourages branching and merging often. But SVN might have cheap branching now, as another commenter implies.
I do not remember if "stat" was particularly slow, but SVN in general is slow.
svn status, even for an entire repo checkout (which is not common) is also fast.
And yeah, it has virtue of simplicity as well doing very well at narrow and shallow even though I'd love to have mercurial's feature set.
It's also rather good in the "wiki" situation since people can operate on their single files without needing to update, sync and merge.
https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...
A fun rant, even though git has gotten better-ish at large files.
> Creating branches is virtually instantaneous. It's just a copy which is a free operation (just a link).
What version SVN are you using? I'm certain that older SVN versions would actually copy the entire project's files, not symlinks but real copies. That would take forever and running out of disk space was a real concern.
I can perhaps imagine a large repo plus a broken svn client requiring checking out unneeded portions of trees to do a copy, but no client I've used works like that.
Hm. Another theory. Perhaps someone who knew nothing about svn and was using TortoiseSVN's Windows file manager integration was doing a Windows file manager copy, then checking that in as a "branch" with the only link being the commit message instead of using svn's copy which is free and properly links content. That would indeed be an expensive operation, and the wrong thing to do.
I have this alias in my .hgrc file fad=fastannotate -u -n -wbB --deleted
It's by the Facebook engineer Jun Wu who also made the even more awesome "absorb"
It's perfectly fine to use Git to track things other than sourcecode. In fact, right on the manpage, Git calls itself "the stupid content tracker".
I've been using Git with git-annex to track archival files with their associated metadata. We keep our data separate from our sourcecode, and segment our data into individual Git repositories for each collection. Git gives us many features that we would have had to build into our app in other ways (data integrity, fixity, etc), though this came with costs.
To my eye it probably would have been better for Canva to use multiple separate repositories instead of a monorepo, but I'm not them and their use-case is not mine.
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, we can throw all these generated files into git!". 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??"
Given that 70% of their repo is generated files, that discussion and the tradeoffs involved don't get nearly enough attention from OP.