Specifically, here is what I read that made me think otherwise:
If your changes pass, TeamCity (in cooperation with your IDE)
AUTOMATICALLY commits them to Version Control.
The "in cooperation with your IDE" is what concerned me. Is it
expecting your IDE to hang around?
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 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. And even this will
probably have plenty of issues, but it seems more sane to me.
-----Original Message-----
From: news [mailto:news_at_ger.gmane.org] On Behalf Of Harshad
Sent: Saturday, September 06, 2008 11:45 AM
To: users_at_subversion.tigris.org
Subject: RE: Re: Automatic build of source on every check-in
TeamCity does the commit directly, if it's a good commit. This page
makes it
clear:
http://www.jetbrains.com/teamcity/delayed_commit.html
That should reduce the round-trip time for the client and the problems
you
listed probably vanish.
---------------------------------------------------------------------
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 00:45:18 CEST