incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stahl <...@openoffice.org>
Subject Re: fetch-all-cws.sh (was: Building a single Hg repository)
Date Sat, 02 Jul 2011 13:37:05 GMT
On 02.07.2011 04:14, Greg Stein wrote:
> On Fri, Jul 1, 2011 at 17:18, Greg Stein<gstein@gmail.com>  wrote:
>> On Fri, Jul 1, 2011 at 16:58, Michael Stahl<mst@openoffice.org>  wrote:
>> ...
>>> 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!
>
> I used that code to figure out which are empty, and then commented
> those out from the cws-list.txt file. I think it is best to keep the
> code in there, regardless. Somebody may want run it in the future.
>
> When I was working on this, however, I noticed we were not attempting
> to fetch the cws_l10n repositories. So I fixed the filter, but
> Mercurial said those repositories are not related to DEV300. What is
> going on there, and what do we need to fix? Should we be fetching the
> cws_l10n/* repositories? And if so... how do we integrate that into
> our single repository, and then into our svn repository?

these need to be pulled into the l10n repository, not the main repository:
http://hg.services.openoffice.org/master_l10n/OOO340/

and i'd expect almost all of these to be empty.

the l10n repo contains a single top-level module.

we could integrate these in SVN in 2 ways:
1. like we did in the old times, as a top-level module next to all
    the other ones:
         ooo/trunk/{hundreds of modules}
	ooo/trunk/l10n

2. under a separate root:
         ooo/trunk/{hundreds of modules}
	ooo-l10n/trunk/l10n

1. has the advantage that everything can be branched/tagged in one 
operation, while 2. has the advantage that it's easier for developers 
that only build en-US to not waste disk space/build time (the build 
system is already prepared to have it "optional").

(of course there are other ways we could split up the modules, like e.g. 
have a separate Apache URE product upon which Apache OOo can depend, but 
that's not something we should discuss now...)

-- 
"Inexact sciences like economics advance funeral by funeral."
  -- Paul Samuelson


Mime
View raw message