Subversion transactions within post-commit
Hi list I've been stumped by this issue for months. I had never enough time to troubleshoot it, so I'm finally desperate after having spent an entire day trying to figure things out. We have a _local_ checkout of the repository on our server, and our post-commit hook needs to run svn-add, svn-rm and svn-ci commands in that checkout. All of these commands run fine. For eg. (within the post-commit script): echo "Updating..." svn up would yield: Updating... Updated to revision $whatever. And: echo "Adding..." svn add would output: Adding... A $whatever Now comes the interesting part. As soon as I add a commit transaction, say, AFTER those commands, ALL of them FAIL at the SAME TIME: echo "Updating.." svn up echo "Adding..." svn add $whatever echo "Committing..." svn ci -m "$whatever" gives us: Updating... svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Adding... svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Committing... svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Notes: * It is always reproducible. I just remove the commit command from the script and everything works as expected. * The owner of the checked out repo is a normal user of the web account, but post-commit is run by 'apache'. * We have the repo chown'ed to $user:$user and perms set to 775. * The user 'apache' is also part of the group $user, but the user $user is _not_ part of the group 'apache' (not possible for security reasons on the server). * As such, both the currently logged in user and 'apache' can at least do update transactions without any errors. Another very important note: * Since post-commit runs as 'apache', some Subversion files (not sure which) are created with perms 444. Would appreciate some help in this matter. Thanks! -- GPG/PGP ID: 19BAA7AD
Re: Subversion transactions within post-commit
On 3 August 2011 04:37, David Weintraub wrote: > NO! NO! NO! AUUUGGGHHH! > > Never update a repository with a hook.! That's why you're given the > relatively safe "svnlook" command. It allows you to look, but not > touch a repository. > ... > SNIP > ... Arrrgghhh damn it! Exactly what I feared. Especially the recursion. So much so that now I think I was in denial all the while. OK, looks like I have to explain a bit further to clear this up and hopefully get some solutions. We use the repository to directly serve some files (so Subversion updates are immediately reflected). Something like http://subversion.apache.org/faq.html#website-auto-update So $files.subdomain.org/public_html is actually a local checkout of $svn.subdomain.org/public_html/trunk/$somedir, and whenever someone commits something to the SVN repo, the post-commit hook updates the local checkout. So anyone browsing the file server will get the most recent files. However, we need to be a bit more personal than that. We need to do some checks on those files and remove ones that should not be there. We need to do this immediately after the commit, so cron is not an option. How should we go about doing this? -- GPG/PGP ID: 19BAA7AD
Re: Subversion transactions within post-commit
On 3 August 2011 05:47, Nico Kadel-Garcia wrote: > That's what "svn checkout" for initial setup, and "svn update" or "svn > revert" of the local copy are for. We already have that working, I just outlined the current setup: http://files.foobar.org/ is a direct file mirror (less revision control; plus additional files generated post-commit dependent on the latest version of each revision controlled file) of http://svn.foobar.org/trunk/somewhere. Developers push stuff to somewhere (which is private in Subversion). This private area then gets served as HTTP/FTP, edited appropriately for public use (and also for programs as some of the files generated after a commit are databases). > Then you do your updates in a working copy as part of a working copy, > and that copy has a deployment script or "Makefile" that does "rsync" > or other mirroring tools to publish those changes to your exposed > website. I like "Makefile" bassed approaches, myself, so I can do > "make", "make test", and "make install". Ahh yes. This was one of our earlier plans, but I scraped that because it would duplicate the contents (of the SVN repo) on the server. But let me get this right: svn commit (anywhere) -> post-commit -> svn up (local checkout), rsync -> local mirror -> edits ? -- GPG/PGP ID: 19BAA7AD
Re: Subversion transactions within post-commit
On 4 August 2011 01:59, David Weintraub wrote: > ... > SNIP > ... > I have what I call my Kitchen Sink pre-commit trigger that does all > sorts of stuff. One of the tasks it can do is "ban" files based upon > their name (either regular expression or Ant glob). If a user adds a > file with a forbidden name, the commit is rejected and the user is > informed of the offending file. The user has to remove the file from > their commit and try again. Thanks guys. I'm just stupid. I've been going on and on about what we want to do, but I haven't even stated the obvious: * It's just about removing stale files from being tracked by Subversion, _without_ committer intervention. Basically, our developers (did|can do) this thing manually (remove an older version of a binary they are committing). I wanted to automate this. That's all! So, after the discussion here, it's evident I'm doing this all wrong. I've now just reverted our stuff to the last best working state, and I'll be working on something based on: pre-commit (as much filtering as possible during this stage) post-commit (update the checkout) rsync (mirror the checkout for publishing; do not reflect stale files) cron (to svn rm; svn ci the stale files) -- GPG/PGP ID: 19BAA7AD
[svn-policy] Anonymous read in toplevel but deny read deeper
Hi all I have something like the following: [groups] admin = joe contrib = susan, mark devs = andy, jane [/] * = r [/trunk] @admin = rw [/trunk/contrib] @contrib = rw @devs = rw [/trunk/dev] * = @contrib = @devs = rw Unfortunately, authentication does not work, and anyone can read '/trunk/dev' and I guess that is due to '* = r' in toplevel. Strangely, it works for groups, the only change being: [/] @contrib = r And nothing for '*' anywhere, that would prevent anyone in the group 'contrib' to pull '/trunk/dev' in a full checkout. But this then locks out anonymous read-only full checkouts (I can have '* = r' for each dir except 'dev'), which I do not want. Thanks beforehand! -- GPG/PGP ID: B42DDCAD