On Wed, Jan 5, 2011 at 17:03, <eric.b...@barclayscapital.com> 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.
Depending upon what your hooks do, they may require a full working copy (and thus client executable) to operate. > 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. One breaking point in my mind is "how long will this take?". If it's a very fast script to execute then a hook script is probably fine. If it's a compilation & test suite execution, that could take minutes or longer. One of my projects takes 15 minutes to do a full compile & deploy; I can't hold every other commit to the repository for that. > How would hudson help to validate files in the context of a checkin > transaction? A CI server would do the validation after checkin (allowing the checkin to be very fast), and send notifications in the case of errors (or success, for that matter). > ________________________________ > From: David Weintraub [mailto:qazw...@gmail.com] > Sent: Wednesday, January 05, 2011 4:37 PM > To: Berg, Eric: IT (NYK) > Cc: users@subversion.apache.org > Subject: Re: Hooks That Use Perl Test::Builder Having Problems with STDERR > > On Wed, Jan 5, 2011 at 11:30 AM, <eric.b...@barclayscapital.com> wrote: >> >> I'm working on porting a fairly extensive set of CVS hooks to SVN. > > Okay. Stop right there. When ever someone mentions "a fairly extensive set" > of hooks, I start to think maybe most of what they want shouldn't > necessarily be hooks. When hooks are running, the client is sitting there > waiting for the results. I've been at one place where it wasn't unusual for > a commit to take almost a minute for reformatting, testing, etc. Those were > a group of very frustrated developers. > Besides, how can you even run your tests? The hooks execute on the > Subversion server, yet the working directory is on the client There's no > communication between the server and client until the hooks are complete. >> The issue that I'm having now is that my pre-commit hook, which runs a >> Perl script >> that performs tests based on Test::Builder and Test::More, never show >> their stderr >> on the console. I see it in the svn web server logs, but not on the >> console. > The problem is that Subversion swallow STDOUT and STDERR from the hooks, and > Subversion won't display STDERR unless the hook script returns a non-zero > exit value, and only then, it displays it on the developer's console. That > may be your problem. > Do you have continuous build server like Hudson (http://hudson-ci.org)? > Even if you don't need to compile code, you can use something like Hudson > for running your tests. Hudson can checkout the project from the Subversion > repository, run tests, and then report back the results. > Moving your testing to Hudson will simplify your life and help keep a > running record of your test results. Hudson won't interfere with > Test::Builder and Test::More, and you'll be able to keep the test results of > all of your check ins in one easy to find place. > -- > David Weintraub > qazw...@gmail.com > > _______________________________________________ > > > > This e-mail may contain information that is confidential, privileged or > otherwise protected from disclosure. If you are not an intended recipient of > this e-mail, do not duplicate or redistribute it by any means. Please delete > it and any attachments and notify the sender that you have received it in > error. Unless specifically indicated, this e-mail is not an offer to buy or > sell or a solicitation to buy or sell any securities, investment products or > other financial product or service, an official confirmation of any > transaction, or an official statement of Barclays. Any views or opinions > presented are solely those of the author and do not necessarily represent > those of Barclays. This e-mail is subject to terms available at the > following link: www.barcap.com/emaildisclaimer. By messaging with Barclays > you consent to the foregoing. Barclays Capital is the investment banking > division of Barclays Bank PLC, a company registered in England (number > 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. > This email may relate to or be sent from other members of the Barclays > Group. > > _______________________________________________