openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: (was: Building a single Hg repository)
Date Fri, 01 Jul 2011 21:18:02 GMT
On Fri, Jul 1, 2011 at 16:58, Michael Stahl <> wrote:
> On 01.07.2011 13:42, Greg Stein wrote:
>> This is the approach that I took. Please look at
>> tools/dev/ 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.
> indeed, i get similar numbers.
> a clone with hardlinks is 34 MB on my filesystem.
> a CWS with a single changeset takes 670MB.
> reason is that for every commit, 2 files that store changelogs and manifests
> are modified, and together these are >600 MB in our repo.

While away from the laptop, I realized that I may have messed up the
counting due to the hardlinks. But I find that 'du' counts files just
once per execution, which is the right thing.

So it is good to see you have an explanation for why it takes so much space.

> but actually i think that a lot of these 250 CWSes will not contain a
> changeset that is not in the master already; a lot of developers create new
> CWS and then (have to) work on something else for some weeks...
> so i have adapted the fetch script to skip empty CWSes.

Saw that. Great!

>> 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).
> this would of course take much less space, but then it would be necessary to
> mark the newly pulled head immediately to know which CWS it corresponds to.

Could you review Herbert's script? I think we'd actually put that into, and delete the script as unneeded.

Is that a safe approach? What happens if it stops part way through?
Can it be restarted with minimal effort? And what happens to the
bookmarks in such a case?

>> 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.
> i have checked the status in EIS, and it seems like the repos for almost all
> integrated/deleted CWSes have already been automatically removed from the
> server.
> found a couple that were in a state "cancelled", which i didn't even know
> existed, sounds like we don't need those, so i've commented them out.


> of course some CWSes contain stuff that's not useful, but i don't know which
> these are :)

Right. I think we just bring it all over, and then sort it out in our


View raw message