Gleason, Todd wrote:
> And even if it doesn't tie up your local machine, if you "commit" with
> TeamCity and then update, what happens? Do your files stay in their
> modified states (making a subsequent commit problematic) while the build
> runs? Or does something else happen? Does TeamCity flag your changes
> somehow and exclude them from a subsequent commit?
I have never used it, so I don't know. I am not in favour of using it
anyway; I just posted it as it came closest to what I originally wanted.
> I think in general, I'd vote for a post-commit solution to this problem.
> If you want more control, I'd make people commit to a separate
> "unstable" location, verify with the post-commit build, and then
> automatically merge over to the "stable" location.
Good idea. I assume that the post-commit hook would queue up a request to a
build server and return immediately, so that the client doesn't block. The
only negative I see in this is that it is a bit complex to implement than
the pre-commit hook.
I would vote for a slight modification to the above though I don't know if
it is feasible in subversion. It seems to work better when there is tag
support (as implemented in CVS/Perforce). In this approach, commits to the
trunk, or top-of-the-tree in general, are uncontrolled. But there is
a "stable" tag which only gets updated if tests pass. This update can
happen in the background by the build-server. And everybody is encouraged
(disciplined) to always work off the stable tag.
I have seen and used this in a previous life and it was very effective. But
this was an in-house solution built around Perforce, with several
person-months of effort behind it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-07 06:06:34 CEST