On Tue, Jan 26, 2010 at 15:56, Tucker <junk_at_gmail.com> wrote:
> Does anyone know of a, relatively, simple way to block commits,
> without approval? For the sake of context, here's the actual need:
>
> The company I work for has decided (correctly) that we need to keep
> out system configuration scripts (puppet) in Subversion. Migrating
> all of this is a rather trivial task but adding sanity to changes is
> one of my top priorities. Since puppet has the power to do "Bad
> Things," when you mess up a config, we'd like to require change
> approval. The suggestion I've heard, thus far, is to have release and
> development branches and integrate from the dev branch, once a change
> has been approved. While doable, this isn't the most scalable
> solution. What I'd like to see is something more like this:
>
> 1) Admin makes a change and attempts to commits
> 2) Pre commit sends out a request for peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the original admin can now commit to release branch
>
> Using dev and release branches, something like this seems feasible:
>
> 1) Admin makes a change and commits to dev branch
> 2) Post commit hook sends email, requesting peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the change is picked up by a cron script and
> integrated into release branch
>
> Now, where my complete lack of SVN skills show is that I don't know if
> this is possible. Are there additional tags (META?) that can be added
> to commits, that can make one of these scenarios possible? Are there
> existing hook recipes, that someone knows of, that could help me along
> the way? Any insight is appreciated.
Rather than doing it automatically (which may not be possible - the
merge might detect conflicts), why not place the responsibility of
reintegrating (step 4) onto the shoulders of the admin who
reviews/approves (step 3)?
Received on 2010-01-26 22:31:53 CET