On Tue, Jan 26, 2010 at 1:10 PM, Bob Archer <Bob.Archer_at_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
Received on 2010-01-26 22:38:56 CET