2012/12/24 Brett Porter <[email protected]>: > I had the same feeling pushing up Continuum's Maven site recently... > > On 23/12/2012, at 9:36 AM, Olivier Lamy <[email protected]> wrote: > >> 2012/12/22 Kristian Rosenvold <[email protected]>: >>> 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 > [email protected] > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > http://twitter.com/brettporter > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
