master_l10n (was: fetch-all-cws.sh)

[Greg Stein <gs...@gmail.com>]

I'm working on fetching all the Hg repositories and wanted to come
back to the l10n stuff. We need to include that in our migration
(correct me, if I'm wrong).

On Sat, Jul 2, 2011 at 09:37, Michael Stahl <ms...@openoffice.org> wrote:
> On 02.07.2011 04:14, Greg Stein wrote:
>...
>> 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/

Gotcha. Okay. I'll expand the script to working against this master,
and then fetch cws_l10n repositories against that.

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

Okay. I'll comment them out in cws-list.txt as I find them.

> 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

I'm going to suggest we do this:

3. as sibling to trunk and our other high-level directories:

   ooo/trunk/...
   ooo/l10n/...
   ooo/tags/...
   ooo/branches/...
   ooo/site/...

That has the advantage of avoiding the l10n data when working on
trunk. When we copy trunk to a new branch, we can copy l10n into that
copied trunk, or as a sibling branch. I think that will depend on how
we'd like to manufacture a release, and I don't have the data for
that.

PMCs generally get one directory in the ASF repository:
repos/asf/PMC/.... The above structure maintains that, and keeps l10n
data out of trunk.

Another option would be to use option (1), and if people don't want
the data, then they can use "shallow" working copies[1]. This requires
a bit more activity from the developer, and I think it would be
simpler to follow the *typical* case of not wanting the l10n data by
omitting it from trunk.

Cheers,
-g

[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html

Re: master_l10n (was: fetch-all-cws.sh)

[Eike Rathke <oo...@erack.de>]

Hi Greg,

On Friday, 2011-07-08 15:22:36 -0400, Greg Stein wrote:

> I'm going to suggest we do this:
> 
> 3. as sibling to trunk and our other high-level directories:
> 
>    ooo/trunk/...
>    ooo/l10n/...

+1

> That has the advantage of avoiding the l10n data when working on
> trunk. When we copy trunk to a new branch, we can copy l10n into that
> copied trunk, or as a sibling branch. I think that will depend on how
> we'd like to manufacture a release, and I don't have the data for
> that.

I suggest to use a sibling also for new branches, that way working on
a branch is similar to working on trunk.

> [...]
> Another option would be to use option (1), and if people don't want
> the data, then they can use "shallow" working copies[1]. This requires
> a bit more activity from the developer, and I think it would be
> simpler to follow the *typical* case of not wanting the l10n data by
> omitting it from trunk.

Usually code developers don't need the l10n repo unless they want to
build with an additional language.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD