www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Herbert Duerr (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (INFRA-5590) Creating a Git-Mirror of the Openoffice code base
Date Tue, 12 Nov 2013 16:36:18 GMT

     [ https://issues.apache.org/jira/browse/INFRA-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Herbert Duerr updated INFRA-5590:
---------------------------------

    Description: 
The OpenOffice project would benefit from having an official git mirror of its codebase. Following
http://www.apache.org/dev/git and the mailing list thread on http://mail-archives.apache.org/mod_mbox/openoffice-dev/201211.mbox/%3C50B88C50.7020506%40apache.org%3E
here are the requested infos:

- Name of the codebase: "Apache OpenOffice"
- Name of the requested Git mirror: "openoffice.git"
- Subversion path of the codebase: "openoffice" (was "incubator/ooo")
- Subversion layout: There is the standard "trunk, branches, tags" layout, but there also
exist other top-level directories such as devtools, ooo-site, pmc, site, symphony, and trunk-orig.
Except for the symphony directory these do not really belong to the codebase (as released
in source tarballs) so these extra directories can and should be omitted in the git-mirror
if they complicate things too much (having the symphony/trunk directory as a branch would
be nice though).

Another complication comes from the fact that most branches are one-level deep, but some are
two levels deep (e.g. branches/alg/aw080). Yet another complication comes from having history
in the pre-graduation "incubator/ooo" tree and in the post-graduation "openoffice" tree. The
11-year pre-ASF history of the original OOo project is also available.

The sizes of current trunk/main + trunk/test + trunk/ext_libraries are 680MB + 50MB + 220KB,
the size of the localization data in trunk/extras is another 930MB. The localization data
compresses well but can be considered an own entity, if this makes things easier or more manageable
(e.g. the old OOo project had separate repositories for the code and the l10 data). The tarballs
in trunk/ext_sources used another big chunk of up to 200MB, but they can be omitted altogether,
as these external dependencies are fetched after the configure step from their respective
original or more reliable backup locations.

  was:
The OpenOffice project would benefit from having an official git mirror of its codebase. Following
http://www.apache.org/dev/git and the mailing list thread on http://mail-archives.apache.org/mod_mbox/openoffice-dev/201211.mbox/%3C50B88C50.7020506%40apache.org%3E
here are the requested infos:

- Name of the codebase: "Apache OpenOffice"
- Name of the requested Git mirror: "openoffice.git"
- Subversion path of the codebase: "openoffice" (was "incubator/ooo")
- Subversion layout: There is the standard "trunk, branches, tags" layout, but there also
exist other top-level directories such as devtools, ooo-site, pmc, site, symphony, and trunk-orig.
Except for the symphony directory these do not really belong to the codebase (as released
in source tarballs) so these extra directories can and should be omitted in the git-mirror
if they complicate things too much (having the symphony/trunk directory as a branch would
be nice though).

Another complication comes from the fact that most branches are one-level deep, but some are
two levels deep (e.g. branches/alg/aw080). Yet another complication comes from having history
in the post-graduation "openoffice" tree and in the pre-graduation "incubator/ooo" tree. Pre-ASF
history is also available.

The sizes of current trunk/main + trunk/test + trunk/ext_libraries are 900MB + 100MB + 128K,
the size of the localization data in trunk/extras is another 860MB. The localization data
compresses well but can be considered an own entity, if this makes things easier or more manageable
(e.g. the old OOo project had separate repositories for the code and the l10 data). The tarballs
in trunk/ext_sources used another big chunk of up to 200MB, but they can be omitted altogether,
as these external dependencies are fetched after the configure step from their respective
original or more reliable backup locations.


> Creating a Git-Mirror of the Openoffice code base
> -------------------------------------------------
>
>                 Key: INFRA-5590
>                 URL: https://issues.apache.org/jira/browse/INFRA-5590
>             Project: Infrastructure
>          Issue Type: Task
>      Security Level: public(Regular issues) 
>          Components: Git
>            Reporter: Herbert Duerr
>
> The OpenOffice project would benefit from having an official git mirror of its codebase.
Following http://www.apache.org/dev/git and the mailing list thread on http://mail-archives.apache.org/mod_mbox/openoffice-dev/201211.mbox/%3C50B88C50.7020506%40apache.org%3E
here are the requested infos:
> - Name of the codebase: "Apache OpenOffice"
> - Name of the requested Git mirror: "openoffice.git"
> - Subversion path of the codebase: "openoffice" (was "incubator/ooo")
> - Subversion layout: There is the standard "trunk, branches, tags" layout, but there
also exist other top-level directories such as devtools, ooo-site, pmc, site, symphony, and
trunk-orig. Except for the symphony directory these do not really belong to the codebase (as
released in source tarballs) so these extra directories can and should be omitted in the git-mirror
if they complicate things too much (having the symphony/trunk directory as a branch would
be nice though).
> Another complication comes from the fact that most branches are one-level deep, but some
are two levels deep (e.g. branches/alg/aw080). Yet another complication comes from having
history in the pre-graduation "incubator/ooo" tree and in the post-graduation "openoffice"
tree. The 11-year pre-ASF history of the original OOo project is also available.
> The sizes of current trunk/main + trunk/test + trunk/ext_libraries are 680MB + 50MB +
220KB, the size of the localization data in trunk/extras is another 930MB. The localization
data compresses well but can be considered an own entity, if this makes things easier or more
manageable (e.g. the old OOo project had separate repositories for the code and the l10 data).
The tarballs in trunk/ext_sources used another big chunk of up to 200MB, but they can be omitted
altogether, as these external dependencies are fetched after the configure step from their
respective original or more reliable backup locations.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message