Indeed… at the moment it looks like it’s doable if you’re:
- patient (expect hours, not minutes)
- not stingy with RAM (for a repo this size, 2GB should be considered a minimum.)
For smaller repositories, it JustWorks™. gitea is just perfect for tracking smaller upstream projects, it’s just the Linux kernel that it chokes on, and understandably so, there’s over a decade’s worth of commit history there. It’d be worse if I pull in the Linux/MIPS tree: their repo goes back to kernel 1.x (mid 90s, when they used CVS).
I think my problem is exacerbated by the fact that I allocated 512MB RAM for the VM thinking “that ought to be enough”. I checked this morning, and saw that it had pulled in the initial push from
linux-temp into my mirror, so I pushed some more and told it to sync again.
I think a few more iterations of this, and I’ll be ready to switch it to use a real outside mirror.
I can of course shut down the VM and allocate more RAM… and I can also buy more ram for the VM host (already thinking of doing this, although ECC SO-DIMMs are rare and expensive, that’s the type of RAM my nodes take).
Thinking about how to solve this long-term… and I come at this not being a Go programmer… but perhaps the clone process could be forked into the background, then after a timeout if it is taking longer, it sets a flag on the repository then displays a page to say the clone is taking place in the background. If someone hits the repository during this time, they get told the same thing.
When the clone completes, the flag is cleared and users can then see and use the repository as normal.
If a clone fails (and this is the critical bit), it blows away the repository then sends the owner a message notifying them of the failure. That way they’re not left with a repository that just coughs up error 500 that can’t be easily removed (I managed to completely break gitea, necessitating a re-install last time).
It’s nice though having this feature at all, and I appreciate the effort on gitea. It’s one of the few decent repository host systems I know of … the other I was thinking of using was Girocco (which runs repo.or.cz), having tried Gitlab (which doesn’t do mirroring unless you’re an enterprise customer).