Developers often put off checking in. They put it off because they don't want to affect other people too early and they don't want to get blamed for breaking the build. But this leads to other problems such as losing work or not being able to go back to previous versions.
My rule of thumb is "check-in early and often", but with the caveat that you have access to private versioning. If a check-in is immediately visible to other users, then you run the risk of introducing immature changes and/or breaking the build.
The nice thing about private versioning is that in most cases the versions checked in are stored on the server and available to other users if they need them, but don't cause problems the way that making them public can.
I find that when developers have access to private versioning, they tend to start relying on it and it requires no effort on the part of the cm admin to "enforce."
1 comment:
Hi,
I am a little bit more radical than that depending on the project phase. On development phase, I prefer to have the whole team commit at least daily. Developers who want to commit only when it's finished have a higher chance incur in problems at integration time (and they often get as close as possible to the deadline).
I normally prefer to "waste" 5 minutes in clarification on an incomplete feature, instead of discovering at the very last moment that is simplemented in the wrong way.
If we are in a later iteration, or protoryping several options, then I switch to private area and make "release composition" an explicit operation. Private versions or branches come pretty handy here.
Post a Comment