incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From IngridvdM <>
Subject Re: OOO340 to svn - directory setup
Date Wed, 03 Aug 2011 06:45:58 GMT
Am 03.08.2011 08:12, schrieb J├╝rgen Schmidt:
> On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke<>  wrote:
>> Hi IngridvdM,
>> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>>>> The Hg archive should simply replicate the current structure at OOo,
>>>> also for ease of adding in pending CWSs as branches, so a separate l10n
>>>> repository.
>>> Another good argument to separate l10n from trunk was given in an
>>> earlier thread: This way it is easier for developers to get only
>>> what they will need usually and spare the extra time and space.
>>> I think this is a good argument and I wonder whether we shouldn't be
>>> prepared to identify more such stuff - for example the binfilter.
>> The problem with binfilter is that it depends on modules not in
>> binfilter, changing them incompatibly may entail changes necessary to
>> binfilter, those changes should be in one changeset, which I think is
>> not possible when not in trunk, insights anyone?
> well binfilter is maybe not the best example because in the long term we
> should think about the elimination of binfilter completely. Announcing the
> end of life of these filters, then allow the import only for some time and
> the next step is to drop it ...
Ok agreed, binfilter is not the best example.
But what about the general idea to have a second directory where we can 
place all the stuff that is not needed to build the main office (so not 
needed in the usual day to day work of a code developer), but anyhow 
belongs to the product and to each codeline/release.
Maybe templates or some extensions could qualify for this stuff. Maybe 
we have nothing right now but my point is, if we identify such things 
later I do not want to clutter the directory structure with more and 
more directories next to trunk.

I think even that it would be more natural to have those main office 
components and the extras components both within trunk. That should also 
ease the creation of release branches.
So another suggestion for the directory setup:

   with all the other main office modules
   ooo/trunk/main/sw (writer)
   ooo/trunk/main/sc (calc)
   ooo/trunk/main/sd (draw)
   ooo/trunk/main/chart2 (chart)
   with l10n and maybe more stuff later

   this could look like this for example


Kind regards,

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

View raw message