Update/Merge a working copy from a transaction

[Se...@eaton.com]

Hi,

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).

Has anybody come accross a similiar problem and found a solution?

Sebastian Unger
Software Designer
-----------------------------------------------------------------------------
Powerware, 39 Princess St, PO Box 11-188
Christchurch 8030, New Zealand
Phone: (+64) 3 343-3314, Fax: (+64) 3 343-5100
E-mail: SebastianUnger@eaton.com
Website: www.powerware.com

Re: Update/Merge a working copy from a transaction

[Ryan Schmidt <su...@ryandesign.com>]

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

Re: Update/Merge a working copy from a transaction

[Troy Curtis Jr <tr...@gmail.com>]

On 11/1/06, SebastianUnger@eaton.com <Se...@eaton.com> wrote:
>
>
>
> Hi,
>
> 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).
>
> Has anybody come accross a similiar problem and found a solution?
>
> Sebastian Unger
> Software Designer
> -----------------------------------------------------------------------------
> Powerware, 39 Princess St, PO Box 11-188
> Christchurch 8030, New Zealand
> Phone: (+64) 3 343-3314, Fax: (+64) 3 343-5100
> E-mail: SebastianUnger@eaton.com
> Website: www.powerware.com
>
>

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.

Just my opinion.

Troy

-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org