incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Lohmaier <cl...@openoffice.org>
Subject Re: fetch-all-cws.sh (was: Building a single Hg repository)
Date Fri, 01 Jul 2011 13:06:50 GMT
Hi Greg, *,

On Fri, Jul 1, 2011 at 1:42 PM, Greg Stein <gstein@gmail.com> wrote:
> On Wed, Jun 29, 2011 at 05:04, Michael Stahl <mst@openoffice.org> 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
> [...]
> 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.

Then something is obviously wrong. Or you're using the wrong
tool/parameters to measure disk-usage.  In any case would be helpful
if you stated what cws for example would use up so much more despite
being a clone only.

saying that the local clone+pull uses 2GB or repository-data is hard
to believe, after all the size of a repo-only clone with all cws
pulled in only consumes 2.6GB (all cws=all cws that the tinderbox did
built, this doesn't include cws that are not flagged as public in EIS,
didn't compare how many this would be)
Currently that repo has 134 heads = 133 non-integrated cws/cws with
changes compared to DEV300 (as already integrated cws don't add a new
head, all their changes are included in the DEV300 repo already)

> 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,

Well, stating the obvious: You must not cross filesystems/disk
partitions otherwise you don't get hardlinks. And you should not use
an ancient version of mercurial (but that's true for every vcs)

> 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.

See above much less than 5GB

> 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,

Nothing scary at all. (well, scary to git users who are afraid of
having multiple heads - with git this really is a problem, but it's
very different in hg).

The only thing is to keep track which head belongs to what cws - using
bookmarks was suggested, but if you prefer, you can just keep a flat
list of hg id = head revisions of the cws along with your clone.

ciao
Christian

Mime
View raw message