maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Date Tue, 01 Jan 2013 23:45:03 GMT
Le lundi 24 décembre 2012 14:17:02 Brett Porter a écrit :
> I had the same feeling pushing up Continuum's Maven site recently...
> On 23/12/2012, at 9:36 AM, Olivier Lamy <> wrote:
> > 2012/12/22 Kristian Rosenvold <>:
> >> Svnsubpub is just ridiculously inefficient and we need to do something
> >> about it...
> > 
> > That remember me old time when pushing maven sites to sourceforge tru
> > wagon ftp ... :-)
> Is the main problem the file-by-file nature, or something else (such as the
> size)?
I tried to measure and find facts about this: my conclusion is that it is the 
file-by-file nature
exactly like webdav
notice that we have really a bunch of generated files: did you realize that 
maven-scm site has more files than maven core? that it represents 131 MB, tens 
of thousand of files?

IMHO, if we stored zip files of documentations (or tar, the archive format can 
be discussed) and httpd could serve their content on the fly like if they were 
unzipped, this would be awesome
Apparently, coding an lua script could do the job: just need to find somebody 
able to do it :)

any other idea?
Olivier's idea of a service to get zip file then store unzipped content in svn 
would be less efficient (storing so much generated files in svn is inefficient 
IMHO), but better than actual situation

> >> (insert mandatory rant about how this would be a piece of cake with git
> >> here ->.<- )
> >> 
> >> Would it be possible to use svn copy to clone some initial structure and
> >> then just synchronize with the generated site ??
> > 
> > The issue is we create a new path for each release so we need to add
> > all files. (at least when updating an existing path it's faster).
> I wonder if it is time to revisit that decision - since we seem to only link
> to the main docs anyway and have been pretty good about annotating "@since"
> in the docs. In particular, the javadoc and similar reports like xref and
> emma tend to take up the largest chunk of the site deployments, and they
> have less value over multiple versions for plugins, etc. than they might
> for a reusable library.
> If we were to have multiple versions, perhaps the best way to do that is
> publish to a canonical location, then svn cp that server-side to the
> versioned equivalent.
> Ultimately, you really just want to transport diffs.
> > I have propose (on infra@) to have a service to put the zipped site
> > and then in async mode the zipped file will be unzipped then
> > committed.
> > But still no response....
> I don't recall this, do you have a pointer?
> - Brett
> --
> Brett Porter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message