Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
From: "Bert Huijben" <bert@qqmail.nl>
To: "'Daniel Shahaf'" <d.s@daniel.shahaf.name>,
	<dev@subversion.apache.org>
References: <CAB84uBVL_GR_h09=3BB_QaqMUn+LfXB-x4MqnVjb==D_5d_m=A@mail.gmail.com> <1507075496.3788943.1126959480.40F1005A@webmail.messagingengine.com>
In-Reply-To: <1507075496.3788943.1126959480.40F1005A@webmail.messagingengine.com>
Subject: RE: Workflow for editing the subversion website
Date: Wed, 4 Oct 2017 11:07:12 +0200
Message-ID: <013901d33cf0$2adbc5a0$809350e0$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHUTe1TpRj0QrqLTZd9Hj1CCSBgnwHLqzbuosLm4QA=
Content-Language: nl
archived-at: Wed, 04 Oct 2017 09:07:20 -0000


> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: woensdag 4 oktober 2017 02:05
> To: dev@subversion.apache.org
> Subject: Re: Workflow for editing the subversion website
>=20
> 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].
> >
>=20
> 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).
>=20
> > 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?
>=20
> 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?
>=20
> 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
>=20
> Cheers,
>=20
> Daniel