[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 5 Oct 2017 01:13:34 +0200

On Wed, Oct 4, 2017 at 1:21 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Bert Huijben wrote on Wed, 04 Oct 2017 11:07 +0200:
>> > -----Original Message-----
>> > From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
>> >
>> > 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.
> For clarity, I'm not proposing a move to the CMS; I'm simply pointing out that
> the physical way by which commits port from staging to publish, or from
> publish to staging, may be either 'svn merge + svn commit' or that 'svnmucc'
> replace operation.

Yes, I think we should go for 'svn merge + svn commit'. Committing new
stuff to 'staging', and merging (with complete merges, not
cherry-picks) to 'publish'. It would be good for us, as a project, to
use this sort of workflow in practice, as I think it's a useful
workflow that's used by some Subversion users. So in the interest of
eating our own dogfood ...

I'm just not sure if this will always work out perfectly.

- Maybe we'll have some change on staging that we don't want to merge
to publish (I mean, something like showing a different header or
"staging" watermark, to indicate to users that it's not the production
site). That should be easy: we just 'merge --record-only' that commit
to publish.

- Maybe we'll do some changes directly on 'publish' (intentionally, to
be quick and efficient; or accidentally). Can we just merge those to
'staging', and expect this not to be a problem when merging staging
back to publish later? Where does svn stand currently with holding two
branches in sync, while merges can go in either direction?

Received on 2017-10-05 01:14:07 CEST

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