www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [PROPOSAL] m2 repository management
Date Fri, 03 Mar 2006 05:17:04 GMT
Numbers are:

887M    /www/www.apache.org/dist/java-repository/
 16M    /www/www.apache.org/dist/maven-repository/
2.0G    /www/cvs.apache.org/repository/
297M    /www/cvs.apache.org/maven-snapshot-repository/

jakarta-commons trunk is:  265M

I think our public repo is about 7G or so in size.

What kind of problems did you have?

I'll ask the Infra guys if they think it'll be too much.

Hen

On 3/2/06, Dain Sundstrom <dain@iq80.com> wrote:
> Have you tried using subversion for really large files or a really
> large repo.  In Geronimo we used is about a year ago to keep the tck
> from sun (about 1G) and it couldn't handle it.  Things may have
> changed, but I would not want us to bank on the technology until
> someone built a test bed.
>
> -dain
>
> On Mar 2, 2006, at 9:47 AM, Henri Yandell wrote:
>
> > I'd like to propose the following:
> >
> > * Tighten up on the m2 repositories. Structure it in TLP format, allow
> > PMCs access to only their TLP group (ie:  org/apache/<tlp>). They can
> > structure it internally however they wish (while following the m2
> > repository structure).
> >
> > * Kick out things that don't fit that. iBiblio can continue to be a
> > mess, but our repository would tighten up and over time that would
> > communicate to the rest of the repository world.
> >
> > * Use SVN for all this. It fits our current processes, doesn't rely on
> > accounts on the server, lets us hook commit notifications up to mail
> > repository@apache. It gives us history; especially when a pom or jar
> > had to be changed.
> >
> > * Ideally we'd have svn hooks in place to block things that aren't
> > done right; ie) commits without an md5 etc.
> >
> > * We could have people here doing manual svn updates, or we make it
> > automatic.
> >
> > Hen
>
>

Mime
View raw message