Comments on: Leveraging Subversion Hooks for Fun and Profit http://www.agileweboperations.com/leveraging-subversion-hooks-for-fun-and-profit/ Helping web developers and operations bridge the deployment gap Fri, 19 Mar 2010 21:00:23 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Dan Ackerson http://www.agileweboperations.com/leveraging-subversion-hooks-for-fun-and-profit/comment-page-1/#comment-112 Dan Ackerson Wed, 07 Jan 2009 15:29:53 +0000 http://www.agileweboperations.com/?p=498#comment-112 nice idea, Michal. Thanks for sharing! nice idea, Michal. Thanks for sharing!

]]> By: Michal http://www.agileweboperations.com/leveraging-subversion-hooks-for-fun-and-profit/comment-page-1/#comment-111 Michal Wed, 07 Jan 2009 15:12:42 +0000 http://www.agileweboperations.com/?p=498#comment-111 We have a requirement to use subversion 1.5+ clients, because of a merge tracking feature. To ensure that only 1.5+ clients are in use I have created a start-commit hook that checks for the capabilities parameter - capabilities are also a new feature that came with 1.5, and a "mergeinfo" capability is always there for these clients, so I allow only commits from clients that have this. The start-commit hook looks like this: <code lang="bash"> #!/bin/sh REPOS="$1" USER="$2" CAPABILITIES="$3" # allow only subversion 1.5 and higher to commit - this way we make sure that the whole team installs version 1.5 of subversion that supports merge tracking if echo $CAPABILITIES | grep 'mergeinfo' > /dev/null; then exit 0 else echo "" 1>&2 echo "Commit failed ! Please use at least subversion 1.5." 1>&2 exit 1 fi </code> We have a requirement to use subversion 1.5+ clients, because of a merge tracking feature. To ensure that only 1.5+ clients are in use I have created a start-commit hook that checks for the capabilities parameter – capabilities are also a new feature that came with 1.5, and a “mergeinfo” capability is always there for these clients, so I allow only commits from clients that have this.

The start-commit hook looks like this:


#!/bin/sh
REPOS="$1"
USER="$2"
CAPABILITIES="$3"

# allow only subversion 1.5 and higher to commit - this way we make sure that the whole team installs version 1.5 of subversion that supports merge tracking
if echo $CAPABILITIES | grep 'mergeinfo' > /dev/null; then
exit 0
else
echo "" 1>&2
echo "Commit failed ! Please use at least subversion 1.5." 1>&2
exit 1
fi

]]> By: Dan Ackerson http://www.agileweboperations.com/leveraging-subversion-hooks-for-fun-and-profit/comment-page-1/#comment-108 Dan Ackerson Sun, 04 Jan 2009 19:11:29 +0000 http://www.agileweboperations.com/?p=498#comment-108 Exactly. I'm also trying to learn more about the codebase as well (therefore, I'm enforcing commits with a valid ticket id if applicable too). The CI will be phase two for us, and once we get some test driven development going, I will probably be able to turn off those emails. Exactly. I’m also trying to learn more about the codebase as well (therefore, I’m enforcing commits with a valid ticket id if applicable too). The CI will be phase two for us, and once we get some test driven development going, I will probably be able to turn off those emails.

]]> By: Julian Simpson http://www.agileweboperations.com/leveraging-subversion-hooks-for-fun-and-profit/comment-page-1/#comment-107 Julian Simpson Sun, 04 Jan 2009 16:33:44 +0000 http://www.agileweboperations.com/?p=498#comment-107 Dan, nice article. One thing I was wondering about was the email notifications - I find I need these less and less as CI comes of age. Assuming that your outsourcing means that you want some very detailed records of svn activity? :) Dan, nice article. One thing I was wondering about was the email notifications – I find I need these less and less as CI comes of age. Assuming that your outsourcing means that you want some very detailed records of svn activity? :)

]]>