Subject: Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-04-25 15:30:22
> >The live GIT mirrors of Boost trunk SVN have become a bit stale in recent
> >months [...]
> I tried making a mercurial mirror of the Boost trunk SVN and found
> that it took so long to do the conversion process, that I could never
> get it to complete on my home computer with cable modem internet
> access, but I could get it to complete on a shell account with faster
> trunk access.
I simply allocated an OpenVZ container on my cloud with 64Mb of RAM and
128Mb of swap.
> I also found the resulting repository was *huge* because I had *every*
> revision of boost ever recorded in the svn repository.
Github reckons the entire mirror consumes 700.40Mb. No idea if that's good
> I'm curious if you had different experiences when making a git
To be honest, the process was very straightforward. I configured it as per
subgit's instructions. I set it running. It OOMed a few times, but hardly
unsurprising with 64Mb of RAM for the VM. I simply restarted when it did.
And after a day or two it completed (note that the cloud hardware is a 2Ghz
Core 2 without SSD). Better hardware would be far faster.
> I am more familiar with mercurial than git, and I wanted to make a
> local mercurial repository so that I could work on my changes locally
> and checkpoint them using the version control system instead of manual
> backups. AFAIK, there's no way to record local changes with
> versioning using subversion, there's only committing to the remote
Ah, getting subversion commits to match git commits that's subgit's problem
:). Subgit gives you three sync options, "safe", "somewhat safe" and "not
safe". "safe" locks both subversion and git repos during the sync, however
long that takes, and during which no pushes nor pulls nor checkouts may
happen. So long as you can live with that (I can), the live two way
mirroring works well, but it could be frustrating for users of busy repos.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk