> >
> > 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. :-)
>
You're probably right. We are currently running a scheme, that uses a
build
from post-commit, but that's obviously not enough of an "incentive" to
our
developers. Which, I should say, isn't entirely their fault, since the
build
is currently occasionally corrupting a few files, for reasons beyond the
scope of the list. I am trying simultaniously to come up with a fix for
that
problem and a way of preventing these files to make it into trunk.
Anyway, I am still interested in that svn patch command. Is there any
way of
actually applying a diff generated by svn diff or svnlook diff in the
same
way that an svn merge would have applied it? I think that would be a
very
useful feature. For example, I am quite commonly working with several
working
copies from the same repository location and occasionally I want to copy
some
changes from one WC to another without going through to the lengths of
creating
a branch and switching to it etc. svn diff | patch -d <otherWC> works
fine as
long as no files have been added/deleted or properties been modified.
Then it
fails.
Thanks,
Seb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 2 03:11:37 2006