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@HEAD (creating r43, which replaces staging/ by a copy of publish@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@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.
