Re: preventing commits (this is *not* a classic hook question)
Hi David, thanks, that's awesome! Michael I have a pre-commit hook that stores its configuration inside your repository. You'll need access to the Subversion server to set it up, but once it's setup, you can control access by checking out the control file from the repository, making your changes, and then checking it back in. This is a modification of a hook that I've been using for years. Originally, the control file was kept on the server -- usually inside the hooks directory. However, that meant logging onto the server, and that was getting too difficult to do all the time. Besides, this way, I can track who changed the control file and why. What prevents anyone from changing the control file? The control file is configured, so only the administrators can modify it. You can take a look at it at https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. (Yes, a Subversion hook is stored in GitHub). If you need any further help, contact me at da...@weintraub.name, and I'll see what I can do. -- David Weintraub qazw...@gmail.com
RE: preventing commits (this is *not* a classic hook question)
Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. Create a project in your repository that contains a config file of some type. Give write access to this path only to those people that you want to be able to enable/disable checkins. Create a working copy of said config project and check it out on your svn server. Have your hook script update the working copy (or perhaps have a cron job that updates this wc every 60 seconds or whatever) and read this config file to determine if commits are allowed. All the users will have to do is edit the config file and commit it. BOb A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? If the access is through svn+ssh and you can be granted access to the authorized_keys, you can tweak it to read-only. If it's an Apache based access with HTTPS, you can manipulate the Apache config (which requires reloading the Apache server configuration, or control of a .htaccess file) Means vary depending on which technology you use and what you *do* have access to.
Re: preventing commits (this is *not* a classic hook question)
Bob Archer wrote: Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. Create a project in your repository that contains a config file of some type. Give write access to this path only to those people that you want to be able to enable/disable checkins. Create a working copy of said config project and check it out on your svn server. Have your hook script update the working copy (or perhaps have a cron job that updates this wc every 60 seconds or whatever) and read this config file to determine if commits are allowed. All the users will have to do is edit the config file and commit it. slight modification to that solution: Create a revprop in revision 0 in your repository that contains a the block/noblock information Give write access to this revprop only to those people that you want to be able to enable/disable checkins. Have your hook script check this revprop to determine if commits are allowed. All the users will have to do is edit the revprop (no commit required). Original version has the side benefit of providing an audit trail for the configuration changes. -- Lorenz
RE: preventing commits (this is *not* a classic hook question)
Hello Bob, Nico, Les, thanks for your pointers. Great help, exactly what I've looked for. Thanks!! Michael Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. Create a project in your repository that contains a config file of some type. Give write access to this path only to those people that you want to be able to enable/disable checkins. Create a working copy of said config project and check it out on your svn server. Have your hook script update the working copy (or perhaps have a cron job that updates this wc every 60 seconds or whatever) and read this config file to determine if commits are allowed. All the users will have to do is edit the config file and commit it. BOb A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? If the access is through svn+ssh and you can be granted access to the authorized_keys, you can tweak it to read-only. If it's an Apache based access with HTTPS, you can manipulate the Apache config (which requires reloading the Apache server configuration, or control of a .htaccess file) Means vary depending on which technology you use and what you *do* have access to.
Re: preventing commits (this is *not* a classic hook question)
I have a pre-commit hook that stores its configuration inside your repository. You'll need access to the Subversion server to set it up, but once it's setup, you can control access by checking out the control file from the repository, making your changes, and then checking it back in. This is a modification of a hook that I've been using for years. Originally, the control file was kept on the server -- usually inside the hooks directory. However, that meant logging onto the server, and that was getting too difficult to do all the time. Besides, this way, I can track who changed the control file and why. What prevents anyone from changing the control file? The control file is configured, so only the administrators can modify it. You can take a look at it at https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. (Yes, a Subversion hook is stored in GitHub). If you need any further help, contact me at da...@weintraub.name, and I'll see what I can do. -- David Weintraub qazw...@gmail.com
Re: preventing commits (this is *not* a classic hook question)
On Mon, Mar 19, 2012 at 4:06 PM, Michael Hüttermann mich...@huettermann.net wrote: Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? The hook script is a program that can access any data you want to make available to it. Maybe you should approach the question from the other direction. Who do you want to be able to control the setting, and where can they store something that the hook script can check? -- Les Mikesell lesmikes...@gmail.com
Re: preventing commits (this is *not* a classic hook question)
On Mon, Mar 19, 2012 at 5:06 PM, Michael Hüttermann mich...@huettermann.net wrote: Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? If the access is through svn+ssh and you can be granted access to the authorized_keys, you can tweak it to read-only. If it's an Apache based access with HTTPS, you can manipulate the Apache config (which requires reloading the Apache server configuration, or control of a .htaccess file) Means vary depending on which technology you use and what you *do* have access to.
