> -----Original Message----- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 4 oktober 2017 02:05 > To: dev@subversion.apache.org > Subject: Re: Workflow for editing the subversion website > > 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)
I think we should just use svn merge, to avoid these problems? No CMS here. Bert > > Cheers, > > Daniel