Devil's advocate hat on, and in light of Brane's sibling reply, let me
describe how an svnmucc workflow might work.
Johan Corveleyn wrote on Thu, 05 Oct 2017 01:13 +0200:
> - 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.
With svnmucc, we'll have two options: either revert the change on
staging —
% cd site/staging/
% svn merge -c -42
% svn commit
— or re-create staging from current publish:
% svnmucc rm staging cp HEAD publish staging
> - 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?
To backport from publish to staging, we could either a run cherry-pick
merge, or run the above 'svnmucc rm cp' command. The former would be
preferred if we have other pending changes on staging/ at the time of
the direct commit to publish/. The latter would be more efficient in
terms of developer time.
>
Cheers,
Daniel
P.S. You may have noticed that the use of HEAD in the svnmucc command
introduces a race condition: what if Alice makes a commit to staging
(creating r42) exactly at the time Bob replaces staging by publish_at_HEAD
(creating r43, which replaces staging/ by a copy of publish_at_42), meaning
Alice's commit was immediately reverted by Bob's. If that happens, then
commit notifications will betray it to us, and we'll run 'svn merge -c
42 staging_at_42', thereby dog-fooding the peg-revision codepaths of 'svn
merge' ☺.
P.P.S. Alternatively, Bob could pass "-r 41" to svnmucc, which would
cause his commit command to fail with a conflict.
Received on 2017-10-05 12:30:49 CEST