On Wed, Jan 5, 2011 at 17:03, <eric.berg_at_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:qazwart_at_gmail.com]
> Sent: Wednesday, January 05, 2011 4:37 PM
> To: Berg, Eric: IT (NYK)
> Cc: users_at_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.berg_at_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
> qazwart_at_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.
>
> _______________________________________________
Received on 2011-01-05 23:16:37 CET