www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [PROPOSAL] m2 repository management
Date Fri, 03 Mar 2006 20:26:33 GMT
There were two big problems.  The first was if a file in SVN is  
really big, it can take longer to stream it to the client then the  
svn server allows, and the server hangs up on you.  Depending on how  
we implement this, it may not be a problem. Another form of this  
problem, is you do a commit and the server hangs up on the client  
after receiving the commit and the client does not fully realize the  
local changes.  The only way to fix this is to delete your checkout  
and re-checkout everything from the server.  This would be a big  
problem in a live public repository.

The second problem, was that with a really big repo in terms of the  
number of files, it would take a prohibitive amount of time time (30  
minutes to hours) to run command like svn status, diff, commit or any  
command that required a file scan on the client or server.

This was about a year ago now, so these problems may have been fixed  


On Mar 2, 2006, at 9:17 PM, Henri Yandell wrote:

> 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

View raw message