2012/12/24 Brett Porter <br...@apache.org>: > I had the same feeling pushing up Continuum's Maven site recently... > > On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote: > >> 2012/12/22 Kristian Rosenvold <kristian.rosenv...@zenior.no>: >>> 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)? size of the commit (especially for first commit of a huge site) > >>> (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. > +1
> 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? See Topic "svnpubsub and publication of component documentations" on infra@ > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > http://twitter.com/brettporter > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
