[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 05 Oct 2017 10:30:44 +0000

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.




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

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