On Fri, Nov 21, 2008 at 03:48, Guenter Milde <milde@...> wrote:
> David Goodger schrieb:
>> On Thu, Nov 20, 2008 engelbert gruber wrote:
>>> On Thu, Nov 20, 2008 Guenter Milde wrote:
>> I was not aware that docutils.berlios.de was serving web pages.
> Berlios has basically all the functionality of SF, only without
> advertising :)
I know that. Berlios is a clone of SF, using the GnuForge software
IIRC. What I didn't know was that *docutils*.berlios.de was serving
*our* web pages, in whatever form.
> BTW, we should include Berlios.de providing SVN space in the thanks file.
>> It was only meant to be a staging ground for updating
>> docutils.sourceforge.net, which is the canonical web site.
> I know. However, the aux/ directory was placed under htdocs/ (don't know
> why), so it is served.
I don't know why either. Perhaps for ease of testing.
>> The files under docutils.berlios.de should be removed. Unless someone
>> speaks up, I will do that soon.
> I speak up: Why not using it as a mirror site?
Why do we want or need a mirror site? It just adds complication. I say
we don't need or want it.
We moved the repository to BerliOS when we wanted to switch to SVN,
before SourceForge offered SVN. Prior to that all site-building was
done on SourceForge. But sf.net couldn't access the SVN repo on
berlios.de. So we changed the build script to build the site on
berlios.de and transfer the files to sf.net. Now, with sf.net SSH
access gone, the old model doesn't work any more, and we've switched
to local builds.
We could even move the repo back to SourceForge, since they offer SVN
now. (I'm not suggesting we actually do this. There's no real gain.
And I certainly don't have time.)
> Moving htdocs/aux/htdocs/ to htdocs/, we get a mirror site with no
> additional cost, even auto-updated (if the cronjob remains and the script
> is adapted to the new path). If you agree, I would volunteer to do the
>> We have abandoned BerliOS for building the web site.
> but still the cronjob rebuilds the mirror...
Does it? Whose cron job? It's not mine.
>> It's easier to build it locally and rsync to SourceForge. That's what
>> Engelbert's updated sandbox/infrastructure/docutils-update.local does.
> Is this run by hand every now and then?
I run it whenever I commit to SVN, and often when I notice changes by others.
> Whom should I have to tell to update in case I changed something in the
Me, or this list. Anybody with SVN commit access should be able to run
docutils-update.local. It requires a bit of manual setup initially,
but the script could be updated to handle all that automatically. I
did most of the work in my Polyform Puzzler project:
(the project has a similar layout to Docutils).
>>>> With the --delete option, this could also solve the problem of deleted
>>>> files still lingering on sourceforge.net. (We would need to copy additional
>>>> files on sourceforge once or --exclude them in the rsync command.)
>> Let's not use --delete. There are lots of archived files on
>> sourceforge.net which would not have counterparts on a local build
>> (old versions, etc.).
> But these are static, aren't they?
Yes, but they may change over time.
> So, IMO it is easier to create a
> list of excludes once than to have to manually delete all files that got
> renamed, removed, or moved in the SVN repeatedly (easy but boring).
> Especially the sandbox, as a place to play, is always in flux.
Somebody would have to update the list whenever it the set of files
change, and there would be a danger of accidentally deleting new
If you want to do this, go ahead, but please document the update procedures.
David Goodger <http://python.net/~goodger>