Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 30712 invoked from network); 5 Jan 2011 23:04:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jan 2011 23:04:02 -0000 Received: (qmail 60949 invoked by uid 500); 5 Jan 2011 23:04:01 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 60932 invoked by uid 500); 5 Jan 2011 23:04:01 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 60925 invoked by uid 99); 5 Jan 2011 23:04:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 23:04:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of qazwart@gmail.com designates 209.85.161.171 as permitted sender) Received: from [209.85.161.171] (HELO mail-gx0-f171.google.com) (209.85.161.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 23:03:54 +0000 Received: by gxk8 with SMTP id 8so6631488gxk.16 for ; Wed, 05 Jan 2011 15:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uGOy+ozVlaYSdqW2sEhrme806qsO44Neo1q1IKge3IM=; b=xWZqyB6PXDdXhqIrS5JtEheJr2XOsGaM84bU1uGXjX13Qp/7DHypfME5wUMVIdULwW 99/c4AedNt11XFIwGM0iYfKllioO2QpWjEWhjRlNWIuEr+zRh5YQvhJV3PUX+r3BZjtC InJCQnqVw4Tg9cajCPTMbYeZoT2mnVPi0TQ/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xDvmZCmWXI10riKnFrhowGaX9PE+qjxhKeZw0EgaSYlHAMkcIU/kDG/OvQKfDOKvx5 84ulV3TdbFk26crQl2Qz5vjmTdKOd9qccJAb68KPn+a4aOZTkmlvRG35KlMVes8zUH2X 0/6He93pZhS7hjaChodkYD7zt+m09MJzRN/K0= MIME-Version: 1.0 Received: by 10.236.108.52 with SMTP id p40mr5658120yhg.41.1294268613373; Wed, 05 Jan 2011 15:03:33 -0800 (PST) Received: by 10.236.103.148 with HTTP; Wed, 5 Jan 2011 15:03:33 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Jan 2011 18:03:33 -0500 Message-ID: Subject: Re: Hooks That Use Perl Test::Builder Having Problems with STDERR From: David Weintraub To: eric.berg@barclayscapital.com Cc: users@subversion.apache.org Content-Type: multipart/alternative; boundary=90e6ba4fbf64f1af0f0499216443 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba4fbf64f1af0f0499216443 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 5, 2011 at 5:03 PM, wrote: > Dave, if you look into how the hooks work, basically, they are passed a > repo path and a transaction id that, using svnlook, gives you access to > copies of the working files, so it doesn't matter where the hooks run, nor > is there any requirement for server/client communication. > I've written quite a few hooks. I have a hook script that implements watches. There are many post-commit hooks that set watches, but mine allows the users to set their own by storing the watchlist for each user in the Subversion repository. I use "svnlook cat" to parse out the user's watch list to see if the file being committed is part of the watch. I can do this without having to write the watchlist file into a directory. However, I take it that in order to run the tests, you need these files written to a directory, and you may need dependent files there too. That starts getting a bit more complex than what "svnlook" was built for. In theory, you could checkout a working directory on a hook script, then use "svnlook cat" to update the files that are being committed, and run your tests. It's complex, and can take a long time. Even after all of that, Subversion captures STDOUT and STDERR and they don't get printed out to a console. If you want to see them, you'll have to capture them and then either write them to a logfile, or email them. Though I do love immediate checkins, I'm not sure where you're going when > you suggest that our validations might be better handled some way other than > by hooks. That appears to be the whole reason to have such hooks: to > validate files before allowing a checkin. How long does it take your pre-commit hook to run? Even a few seconds can seem like an eternity to a developer who is making a few minor changes. If every time a developer does a commit, they have to wait, they simply will stop making commits when they should. And, they'll learn to hate Subversion because it is slow and buggy. Remember that Subversion is a version control system which means you can undo stuff that should never have been committed in the first place. Doing tests during the build cycle has lots of advantages: * You have room to checkout your entire project and have access to all the files. That can make running your tests much simpler to do. * You can use Hudson as your framework (or another build server). That means the reporting, running, and checking the results are all done for you. There's no reinventing the wheel. * Your commits are now much faster. * Your tests have their own environment and won't interfere with Subversion * You have a complete log of your tests, and you can review it and see if things are improving. * You have time and resources for more thorough testing * You can notify the entire team when there's an issue. There's always a good chance that the problem isn't in the file being committed, but is located elsewhere. * Most importantly, you'll make your life a lot easier. All you have to do is write the tests and not worry about how you'll run the tests, or how you'll get the output from the tests. It is definitely possible to do what you want, but it will take a lot of work and will probably cause more problems than it is worth.. -- David Weintraub qazwart@gmail.com --90e6ba4fbf64f1af0f0499216443 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 5:03 PM,=A0<eric.berg@barclayscapital.com>=A0wrote:
Dave, if you look into how the hooks work, basically, the= y are passed a repo path and a transaction id that, using svnlook, gives yo= u access to copies of the working files, so it doesn't matter where the= hooks run, nor is there any requirement for server/client communication.

I've written quite a few hooks.= I have a hook script that implements watches. There are many post-commit h= ooks that set watches, but mine allows the users to set their own by storin= g the watchlist for each user in the Subversion repository. I use "svn= look cat" to parse out the user's watch list to see if the file be= ing committed is part of the watch. I can do this without having to write t= he watchlist file into a directory.

However, I take it that in order to run the tests, you need = these files written to a directory, and you may need dependent files there = too. That starts getting a bit more complex than what "svnlook" w= as built for. In theory, you could checkout a working directory on a hook s= cript, then use "svnlook cat" to update the files that are being = committed, and run your tests. It's complex, and can take a long time.<= /div>

Even after all of that, Subversion captures STDOUT and = STDERR and they don't get printed out to a console. If you want to see = them, you'll have to capture them and then either write them to a logfi= le, or email them.

Though I do love immedia= te checkins, I'm not sure where you're going when you suggest that = our validations might be better handled some way other than by hooks.=A0 Th= at appears to be the whole reason to have such hooks:=A0 to validate files = before allowing a checkin.

How long does it take your pre-commit hook to run? Even= a few seconds can seem like an=A0eternity=A0to a developer who is making a= few minor changes. If every time a developer does a commit, they have to w= ait, they simply will stop making commits when they should. And, they'l= l learn to hate Subversion because it is slow and buggy.

Remember that Subversion is a version control system wh= ich means you can undo stuff that should never have been committed in the f= irst place. Doing tests during the build cycle has lots of advantages:

* You have room to checkout your entire project and hav= e access to all the files. That can make running your tests much simpler to= do.
* You can use Hudson as your framework (or another build ser= ver). That means the reporting, running, and checking the results are all d= one for you. There's no reinventing the wheel.
* Your commits are now much faster.
* Your tests have their = own environment and won't interfere with Subversion
* You hav= e a complete log of your tests, and you can review it and see if things are= improving.
* You have time and resources for more thorough testing
* Yo= u can notify the entire team when there's an issue. There's always = a good chance that the problem isn't in the file being committed, but i= s located elsewhere.
* Most importantly, you'll make your life a lot easier. All you ha= ve to do is write the tests and not worry about how you'll run the test= s, or how you'll get the output from the tests.

It is definitely possible to do what you want, but it will take a lot = of work and will probably cause more problems than it is worth..
=
--
David Weintraub
qa= zwart@gmail.com
--90e6ba4fbf64f1af0f0499216443--