> 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
