On Nov 1, 2006, at 18:04, Troy Curtis Jr wrote:
>> I am trying to come up with an improved way of preventing our
>> developers
>> from checking stuff into trunk that doesn't even build. One of the
>> things I
>> am considering is to start off a full build in the pre-commit hook
>> and fail
>> the commit if that does not complete without errors. The problem
>> is, that
>> the script needs to create a working copy that contains the head
>> of trunk
>> plus whatever the user is trying to commit, i.e. the contents of the
>> transaction. One thing I thought I could do, was to do a svnlook
>> diff -t ...
>> | svn patch, but unfortunately svn doesn't have a patch command (I
>> think it
>> should) and the standard patch programs of course don't really do an
>> adequate job (no properties, only working copies of files changed,
>> but
>> nothing added/deleted etc).
>
> It seems like you are trying to be a little too complicated. I would
> think that if you want a 'stable-trunk' model you should have
> developers commit to a development branch and then someone (like you)
> could run periodic tests. Or perhaps you could even do automated
> merges over to trunk after a successful build.
>
> Additionally, if you could implement your proposed pre-commit script,
> what would happen if developer A is waiting for his new code to build
> when developer B attempts a checkin. Of course if all is well then
> developer A's compile will finish first and the commit will happen.
> Now developer B has to wait for his build to (successfully) finish
> before he gets allerted that one of his files is out-of-date! I think
> it would cost more time then just fixing previous bad commits as they
> happen.
yeah.... unless your entire build can happen in seconds, I think it
would get annoying for the developers.
A strategy that others have used, I believe, is to just let people
commit whatever, and then run builds in the post-commit hook instead.
This way developers are not blocked, but testing still occurs. If the
post-commit hook finds a problem, it should send an email to the
entire development team with details of the commit that caused the
problem. This way, the responsible person is given an incentive to
not commit bad code. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 2 02:29:55 2006