On 05.10.2017 01:13, Johan Corveleyn wrote:
> 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.
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
Received on 2017-10-05 09:52:31 CEST