[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Workflow for editing the subversion website

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 04 Oct 2017 00:04:56 +0000

Johan Corveleyn wrote on Tue, 03 Oct 2017 23:32 +0200:
> The recent work on our quick-start.html page by Pavel Lyalyakin
> prompted some thinking about how to better organize our site editing.
> Pavel asked about lightweight branching and Daniel suggested to copy
> site/publish to site/staging and having it served as
> http://subversion.staging.apache.org/ to facilitate previewing [1].

Small technical note: *.staging.apache.org is what the CMS uses, also it
will cause SSL errors since the *.apache.org certificate won't match
that hostname. (Compare svn-eu.apache.org/svn.eu.apache.org: asterisk
in the cert doesn't match dot in the URL's hostname) We can get around
both problems by having the staging preview site live on, say,
https://subversion-staging.apache.org/ (or even on svn-qavm).

> Small changes and corrections can go directly to the live site. Maybe
> we'll need some exceptions for things like news, release notes and
> security pages, which are usually updated as part of releases and get
> a lot of eyes already.
> Thoughts?

I'd like to understand the topology / flow of changes: what ensures that
changes made directly to publish are not reverted by a subsequent
promotion of staging?

FWIW, in the Apache CMS, a "publish" operation uses 'svnmucc rm publish
cp N staging publish', so it's an O(1) operation, but it literally overwrites any
changes that may have been made directly to publish/. (I'm glossing over
a detail but that's the gist)


Received on 2017-10-04 02:05:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.