[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Update/Merge a working copy from a transaction

From: Troy Curtis Jr <troycurtisjr_at_gmail.com>
Date: 2006-11-02 01:04:15 CET

On 11/1/06, SebastianUnger@eaton.com <SebastianUnger@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
Received on Thu Nov 2 01:04:54 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.