On 05.10.2017 01:13, Johan Corveleyn wrote: > On Wed, Oct 4, 2017 at 1:21 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: >> Bert Huijben wrote on Wed, 04 Oct 2017 11:07 +0200: >>>> -----Original Message----- >>>> From: Daniel Shahaf [mailto:d...@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.
Or merge and revert. We do that all the time with BRANCH-README files. > - 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? We do that all the time with regular development branches, too; sync from trunk, then merge to trunk. -- Brane
