On Wed, Jun 29, 2011 at 05:04, Michael Stahl <[email protected]> wrote: >... > in principle the size of a CWS is on the same order as the master, because > it's just another HG repository. > > but HG supports hardlinks between repositories (in newer versions even on > win32), so you can "hg clone" the master on the same filesystem and then > pull in the CWS, and it will be _much_ faster and take _much_ less > additional space
This is the approach that I took. Please look at tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are over 2 Gb each, and another over 1 Gb. And this is with the clone/pull technique. I don't have enough space on my laptop to do a complete trial run. I'm hoping that somebody can figure out how to reduce the disk footprint, or determine that we just have to suck it up. And it would be nice to understand what that target size will be, for all 250 CWS repositories. A possible alternative to pulling N repositories, then combining them in a second step, is to attempt to bring them all into a single repository, one at a time. This is a little more scary for me, not knowing Hg, to understand how restartable and repeatable this process will be in the face of errors. Either starting from scratch, or (I believe an important feature) if it needs to be resumed after some minor failure (eg. network failure). We have a script. It is time to make it work. Michael: you say that some CWS repositories are useless. If so, then please update tools/dev/cws-list.txt to comment-out those CWS's with some explanation for future readers. No need for us to attempt to process them if they're bogus. Any thoughts, please? Cheers, -g
