Pre-Tested Commit: No broken code in your version control. Ever....

w.r.t. the apparent marketing hype in http://www.jetbrains.com/teamcity/delayed_commit.html ...

Really? Never ever?

Granted, the server-side pre-commit build is very cool and closes up a major hole in the build cycle...but it can't close them all.

You've still got checkin skew, which can be significant depending on the team. Consider multiple developers running their pre-commits at the same time on code that is mutually incompatible, but doesn't produce merge conflicts. Their pre-commit personal builds pass and so commit OK, but their changes don't build together. There's no way to reliably catch it, unless...

1) TeamCity were to exclusively lock the relevant code base while it's doing a pre-commit test, which isn't typically a popular policy with dev teams I've known.

2) TeamCity rechecks for updates after the test but before committing, and refuses to commit if more changes are found. I watched this demo, http://www.jetbrains.com/teamcity/documentation/screenshots/TeamCity2.0.VSplugin.html, but didn't see that this check was performed.

-chris

1 comment

w.r.t. the apparent marketing hype in http://www.jetbrains.com/teamcity/delayed_commit.html ...

Really? Never ever?


Well, it's not true in general case. But I should say that with pre-tested commit practice we almost never see builds broken because of compilation errors. You can read more about our own experience with personal builds here: http://teamcitydev.blogspot.com/2008/03/personal-builds-practical-experience.html

Granted, the server-side pre-commit build is very cool and closes up a major hole in the build cycle...but it can't close them all.

You've still got checkin skew, which can be significant depending on the team. Consider multiple developers running their pre-commits at the same time on code that is mutually incompatible, but doesn't produce merge conflicts. Their pre-commit personal builds pass and so commit OK, but their changes don't build together. There's no way to reliably catch it, unless...

1) TeamCity were to exclusively lock the relevant code base while it's doing a pre-commit test, which isn't typically a popular policy with dev teams I've known.


TeamCity does not do this simply because TeamCity does not control access to code repository.

2) TeamCity rechecks for updates after the test but before committing, and refuses to commit if more changes are found. I watched this demo, http://www.jetbrains.com/teamcity/documentation/screenshots/TeamCity2.0.VSplugin.html, but didn't see that this check was performed.


Actual commit is performed from the IDE. If a conflict is detected then commit will fail. Conflicts are detected by version control system not by TeamCity.

--
Pavel Sher

0

Please sign in to leave a comment.