Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Put Half a Million Files in One Git Repository, Here’s What We Learned

canvatechblog.com

Post reply on HN
Print view View original

171–180 of 270 posts

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#171

Post by capitainenemo »

dotancohen wrote: post #115
trasz wrote: post #103

Earlier quoted context omitted.

From my experience SVN isn’t significantly slower than git.

My experience is that anything dealing with a branch, especially but not exclusively creating branches, is very slow in SVN for a repo of any real size, basically anything with a framework. I do not remember if "stat" was particularly slow, but SVN in general is slow.

Huh. 10 gigabyte svn repo at work spanning about 40 projects.. Creating branches is virtually instantaneous. It's just a copy which is a free operation (just a link). Curious as to why it would be slow for you. svn cp https:/ /server/svn/trunk/project/ https:/ /server/svn/branches/project/ticket -m "making a branch here"

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.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#172

Post by kanu666 »

haizzz wrote: post #68
syspec wrote: post #34

The fact that Canva has a `Source Control team` with at least 5 people on it (going by the thanks at the bottom of the article), means they should probably try a different approach. I think it's a cool company, with a good product, but they're WAY too small to be having a "source control team" on staff. That's at least 1.2MM a year salary / benefits cost.

Author here, not everyone on the team works on git and git performance. Our team work on a variety of things that touch "code" in general like our ownership system and tooling, access control, bots and automation, etc...

Thanks for the clarification. How many people work on Developer Productivity in total and what is the percentage from the total engineering headcount?

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#173

Post by AshamedCaptain »

nomilk wrote: post #65

> git status takes 10 seconds on average > running these commands multiple times a day reduces the total productive time engineers have every day I love the attention paid to this. Often opportunities to prioritise seemingly small efficiency gains are neglected. At 10 seconds per command, an engineer that uses git status 50 times per day spends ~10 minutes per day waiting; an entire work week per year!! Well above th…

I used to work at a place where git status would take 2 minutes (or more). You just stop using it and rely more on your memory, or run in it parallel while you continue working on something else, etc.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#174

Post by zoomablemind »

haizzz wrote: post #66
zoomablemind wrote: post #29

> "...we found that .xlf files made up almost 70% of the total number of files. These .xlf files are generated... they are never manually edited by engineers..." First thought is why not to zip/tar away all of these "convenience" files per generation and add a line into build/install script to unpack them after checkout? Additionally, add the .xlf into .gitignore to exclude them from untracked. Noone cares to diff th…

I made another comment as well though tldr is these xlf files are translations tied to texts in code so we can't simply ignore them from the repository. The changes have to be kept so that if we say revert to a certain commit, all the translations match with the texts of headers, buttons, etc...

>...The changes have to be kept so that if we say revert to a certain commit, all the translations match with the texts of headers, buttons, etc...

The mentioned .zip file is to be kept in the repo. Instead of a whatever number of individual .xlf files per generation, these would get zipped together (say, 'assets/xlf.zip') before the commit and the resulting .zip added to the commit.

Similarly, when reverting or on a checkout, it's the .zip that gets checked out and then the .xlf files are unpacked.

The packing/unpacking could be done by the same process that handles the .xlf generation (??build).

Also this may be automated by git-hooks, though it's more natural to handle the packing of assets during the build stage.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#175

Post by AshamedCaptain »

codeyperson wrote: post #119
nomilk wrote: post #65

> git status takes 10 seconds on average > running these commands multiple times a day reduces the total productive time engineers have every day I love the attention paid to this. Often opportunities to prioritise seemingly small efficiency gains are neglected. At 10 seconds per command, an engineer that uses git status 50 times per day spends ~10 minutes per day waiting; an entire work week per year!! Well above th…

It’s actually even worse than that I think. If something takes over a certain amount of time, then I’m more likely to go do something else while I wait, like check Hackernews. And there goes 20 minutes.

I'm hoping at least you acknowledge this is _your_ problem, rather than a tooling problem or the like. You just can't expect everything to give you immediate feedback after a couple seconds.

This is something that's really a degradation of the newer generations of engineers, since I clearly remember the time where these "somethings" would never take less than a couple minutes, and people did not immediately flee to their nearest distraction, but actually planned their time around it. In fact, if you go further back, these "somethings" would have taken hours, and the older generations still got work done.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#176

Post by kanu666 »

hamandcheese wrote: post #160
nvarsj wrote: post #102

Earlier quoted context omitted.

It’s mostly about avoiding code and work duplication. At scale, the waste on duplicate work across teams can be massive (think about setting up CI tooling for example). Mono repo let’s you solve tooling/build problems once and for all. The main drawback is scalability of the tools involved like git.

> The main drawback is scalability of the tools involved like git. And if you can employ enough engineers to break git, you can probably afford a team to work on scaling git.

Git staring to break at 200-300 engineers pushing into it. Scaling git would take 200 more :)

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#177

Post by ililiiilililiil »

milosmns wrote: post #62
syspec wrote: post #34

The fact that Canva has a `Source Control team` with at least 5 people on it (going by the thanks at the bottom of the article), means they should probably try a different approach. I think it's a cool company, with a good product, but they're WAY too small to be having a "source control team" on staff. That's at least 1.2MM a year salary / benefits cost.

Really weird. But maybe this team is in a country where developers cost 100x less? (: Still weird though.

No post body was provided.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#178

Post by aljarry »

rtpg wrote: post #64
Galanwe wrote: post #55

Earlier quoted context omitted.

Sure, how did we ever manage to rename something without monorepos. Oh wait, maybe that's what this "versionning" thing is all about.

Right, it's "I have to send 5 PRs to 5 different repos, get them all cross merged, and then at the end it's wrong anyways so I have to start all over". Multirepo management is extremely frustrating compared to "it's all in the same folder".

At my $dailyjob we (kinda unfortunately) went with tons of repositories and libraries upon libraries, and the only sane way for me to make changes across multiple repos is combining them into single build locally. In .NET it's not that complex - remove a Nuget dependency from your project, and add reference to locally checked-out repository and make sure you're using proper tags. It's mundane, happens to be frustrating, but I can make it work.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#179

Post by arinlen »

tourist2d wrote: post #78
arinlen wrote: post #40

Earlier quoted context omitted.

> I'm not saying don't have the translations at all. I'm saying: 1) caching things in git in general is a bad idea (...) You're missing the point. Storing translated files is caching things in git, and it is not a bad idea. It's a standard practice that saves your neck. You either place faith on a build step working deterministically when it was not designed to work like that, or you track your generated files in you…

> You either place faith on a build step working deterministically when it was not designed to work like that I'm sorry, what? Why would a build not work deterministically? > If you decide to put faith on your ability to run deterministic builds with a potentially non-deterministic system If your build is non-deterministic, how can you have any faith in the binaries it produces? You would have much larger problems in…

> I'm sorry, what? Why would a build not work deterministically?

Because they don't and never did?

Do you understand build systems and individual tools were not designed to ensure deterministic behavior?

https://reproducible-builds.org/docs/deterministic-build-sys...

Anyone with any professional experience developing software can tell you countless war stories involving bugs that popped up when building the exact same project separate times. What leads you to believe that translations are any different? In fact, more often than not we see unexpected changes during translation update steps.

> If your build is non-deterministic, how can you have any faith in the binaries it produces?

First of all, all builds are not deterministic by default.

To start to come close to get a deterministic build, you need to do all your own legwork after doing all your homework.

Did you ever did any sort of this work? You didn't, didn't you? You're not looking and are instead just placing blind faith on stuff continuing to work by coincidence, aren't you?

> You probably don't want to do that (...)

Yes, I do. Anyone with their head on their shoulders wants to do that. It's either that or waste time tracking bugs that you allowed to go to production. Do you want to waste your time hunting down easily avoidable and hard to track bugs? Most of the professional world doesn't.

Re: We Put Half a Million Files in One Git Repository, Here’s What We Learned

#180

Post by kanu666 »

haizzz wrote: post #68
syspec wrote: post #34

The fact that Canva has a `Source Control team` with at least 5 people on it (going by the thanks at the bottom of the article), means they should probably try a different approach. I think it's a cool company, with a good product, but they're WAY too small to be having a "source control team" on staff. That's at least 1.2MM a year salary / benefits cost.

Author here, not everyone on the team works on git and git performance. Our team work on a variety of things that touch "code" in general like our ownership system and tooling, access control, bots and automation, etc...

Sorry, there is a quote from the article: "Kudos to other members of the Source Control team — Alex Sadleir, Wesley Li, Adam Murray, Matthew Chhoeu — who work on improving git performance at Canva"

So I assume 5 people working specifically on Git performance ;-P

Post reply on HN