On Tue, Jan 26, 2010 at 1:10 PM, Bob Archer <bob.arc...@amsi.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. > > I thought I had made a suggestion on how you could create an approval > process... perhaps you didn't see the email.
I must have missed it. I did try a search through my archive, prior to sending out this e-mail. Even looked for anything I sent to the old list that had replies. > > I think a lot depends on if you are looking for a security boundary here or > just a warning type system. It's more about process than security. I don't plan on spending too much effort on figuring out ways to prevent every work around. The focus is more about providing people with a mechanism for doing the right thing and hoping they don't try to get around it. > > 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 pointed out in the reply that just came in, there's an issue with version conflicts. I actually don't want that to be the responsibility of the approver. The approver should be responsible for the changes to the files and, if a conflict arises, the original submitter should have to deal with that. > > 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. Again, that's OK for now. I'm looking into what I can do with properties and auto integration scripts. Thanks for the help. > > BOb > > Comments inline. -- --tucker
