On Nov 11, 2005, at 03:25, Mark Shead wrote:
>> Unless you can compile your project in a few seconds, that's probably
>> not going to be feasible. Every time your users commit they will be
>> waiting for it to do a probably non-instant compile. And while that
>> one user is waiting, no other users can commit either; if they try,
>> they'll be waiting even longer.
>>
>> What's usual is to do just a minimum of testing in the hook, and then
>> let the commit succeed. Then have an automated build that runs
>> nightly or more often if you like. If the build doesn't work, then
>> send an email to the development team saying it's broken, and maybe
>> showing the log of commits that happened since the last time it
>> worked right. That way the user responsible will know it, everyone
>> else will know it, and it will encourage developers to ensure they
>> only commit working code in the future.
>
> That is what we are currently doing. In certian places though I'd
> like the commit to fail unless it builds correctly. It sounds like
> when you check things in, it creates a transaction and then fires
> off the pre-commit scrips. If the script exits with a status of 0
> the transaction is committed.
>
> What I'd like to be able to do is use the script to copy the state
> of the transaction out to a directory and run the build script. If
> it builds then I want the transaction committed. If not I want it
> to abort and the user to be notified.
>
> Obviously this means we'd have to wait around for the build to
> finish, but in our situation that would only mean a few minutes.
> The benefit would is that we wouldn't ever have a case where it
> works on the developer's machine but not on the integration server.
>
> Is this possible?
If you really want to, and your developers will tolerate the delay,
then sure, it's possible. You can use "svnlook changed" in the pre-
commit hook to figure out what files the transaction wants to change.
You could have an up-to-date working copy waiting, and you could then
"svnlook cat" the changed files into the working copy and do the
build. You'll have to devise a mechanism to clean up after the build
when you're done, and to remove the effects of the "cat" commands,
for example by doing "svn revert" on the working copy, then using the
output of "svn statuts" to see what unversioned files remain, and
deleting them.
If you do decide to go this route I'd be interested to know if you
end up being happy with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 11 03:48:15 2005