incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stahl <...@openoffice.org>
Subject Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Date Wed, 10 Aug 2011 19:14:29 GMT
On 10.08.2011 20:10, Mathias Bauer wrote:
> On 10.08.2011 19:13, Dennis E. Hamilton wrote:

>> [Nosing around OpenOffice.org I could find no source repositories,
>> although release tarballs are stated to be available.  I probably
>> don't know where to look.]

look here:
http://hg.services.openoffice.org/

>> (I see that LibreOffice has gotten down to one, but that doesn't help
>> here and I'm not sure what that means in any case.)
>
> I think that you are confusing things here. If you are talking about the
> "one git" effort from LibreOffice: for historical or other reaons
> LibreOffice always had more than one repository for their code base
> (IIRC even more than five), while OOo always only had one until we

in my LO checkout (from before migration) i've got 18 repositories...

there seems to be a script in the top-level that can run git commands 
across all repositories (guess otherwise this kind of setup would be 
completely unusable).

> separated the l10n stuff. As having more than one repository is a major
> PITA for developers if you need them all for even the smalles build,
> they decided to go back to one repository.

there still seem to be 5 repos left (but 3 of them are said to be 
optional: binfilter, dictionaries and translations).

but in any case, LO uses a different model than what OOo used:
- at OOo, we used to have one repo per open feature branch (CWS);
   only very recently have we actually split up the master repo by module
- at LO, all feature branches live in the same repo,
   but they have always split up their code modules across several repos

> As we want to be able to work on each of the cws later, we must be able
> to identify each "tip" change set of all cws in this repo. This can be
> done by keeping each cws in a separate branch or by bookmarking its tip
> change set. The latter is easier to achieve by scripting, the former
> probably would make it easier to work with the cws later. IIRC ease of
> scripting won.

the problem with HG named branches is that they are part of the commit 
metadata, so it's not possible to retroactively introduce them (without 
some effort), while bookmarks are trivial to add.

otherwise, good summary :)

> Regards,
> Mathias

regards,
  michael


Mime
View raw message