> 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.
I thought I had made a suggestion on how you could create an approval process... perhaps you didn't see the email.
I think a lot depends on if you are looking for a security boundary here or just a warning type system.
Your first set of steps is doable but you would have to implement much more of it. Since you don't really want a pre-commit hook to create such a long wait state.
Your second set up steps is probably more workable. Having a checkin of a file with a certain property in a "approval" branch trigger and email or notification of some type to an admin/aprovver... but I would just make step3/step4 be manual so once approved the admin commits the file to the release branch.
As far as metadata... yes, you can create a version property which would trigger your commit script to disallow a check in of certain files. OF course, those properties would be modifyable for the most part which might be ok if you don't need this to be a security boundary.
BOb
Received on 2010-01-26 22:11:01 CET