Le mercredi 2 janvier 2013 23:43:52 Brett Porter a écrit :
> On 02/01/2013, at 10:45 AM, Hervé BOUTEMY <[email protected]> wrote:
> > 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 <[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)?
> >
> > 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?
>
> Yes, similar size in Continuum which I've been working on migrating to
> svnpubsub recently.
> > 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 :)
>
> I've raised this topic and that thread on #asfinfra and will try and follow
> up - I know this was flagged by them some time ago.
> > any other idea?
>
> For now I'm just focusing on reducing the number of changes each site
> deployment to make it a smaller checkin.
>
> See: http://continuum.apache.org/development/publishing-site.html
>
> What I'm doing there is deploying to /docs/latest each time, then copying
> that to the versioned location on the server-side. That way, the next
> version is just the diff against the last, not a whole new one.
ok, that was my first attempts back in july, not based on performance
expectations but simply logic
but the release procedure wasn't easy to automate in Maven: I don't see in
Continuum instrusction where the "svn cp xxx/latest to xxx/<release-version>"
is done. Is it in a Unix shell script?
At that time, the intent was pure logic ("clean work" idea), with impact on
the way to import history: see http://maven.apache.org/plugins/maven-scm-
publish-plugin/examples/importing-maven-site.html
But when Olivier came in to help me, we chose to drop this part and make
simple ("brute force"?) content import and drop this "latest" idea which was
hard to explain
It seems we need to get back to this latest idea since it is really a strong
performance requirement (and efficiency: yes, between 2 maven release, not much
content has changed in the 131 MB)
I had a look at Continuum and I didn't find some thing we do in maven:
- multi-modules sites
- content generation from sources (javadoc, jxr, plugin documentation)
Did I miss something?
>
> There are a few things that cause changes across generation runs:
> - the javadocs generate a timestamp, and this is the biggest culprit as it
> is the largest number of files. I'm going to add -notimestamp tomorrow and
> see if I can get sequential deploys to remain unmodified - most skins
> incorporated a timestamp that changes each build (I've removed that in
> Continuum's skin). The publish date is still there, but it doesn't seem to
> be a big problem. - the dependencies report seems to change between runs
>
> For other reports the change more frequently, I've stopped publishing them
> to the main site. There is Sonar for most of it at
> http://analysis.apache.org/, or you can publish them to a filesystem
> staging in CI and view them through the workspace.
>
> With these sorts of improvements, incremental deployments will actually be
> better than shipping up a large ZIP that gets unpacked, even though it is
> mostly unchanged.
>
> - 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]
