An important part of development in a team based setting is the ability to quickly and easily check in your code, have it built with something like Jenkins, Cruise Control, Team City or Bamboo, get quick results about the compile, integration tests, unit tests, and so on. The results need to come quickly to be of any use.
I have seen .NET developers who are new to the ideas have trouble with the concept of writing small bits of code, making sure tests pass and then pushing them to the source repository in small batches (commits). I should mention, this habit is not restricted to .NET developers only. This is just the topic of the post.
The habit seems to be to work all day then try to do a push at the end of the day. This can cause some significant merge problems and inevitably, defects during the next compile/build/test cycle.
A team member will pull the days' changes into their workstation and find that nothing compiles. This problem eventually turns into a habit of doing the end of day commit an hour before the end of work to deal with the likely problems with the merge.
Sometimes, this results in many hours of work being held off "for now" because it is simply too difficult to merge. The team develops an attitude of "we'll figure it out tomorrow".
In Visual Studio there is an interesting "feature" for managing database interaction called DBML. DBML is sort of control file or schema mapper to allow .NET developers to easily connect to data using one "connection container" or "data context". I am sure there are some technical deficiencies with this comment. That's not the point of this post.
A team using the DBML concept will find that the longer they wait to push their code, the worse their problems will be. The DBML is built in small little cryptic pieces (to the human eye) and becomes almost impossible to merge if two team members have changed it locally.
This means that when you attempt a merge with Git, Mercurial, SVN, etc., you will find that you will have no choice but to basically keep one person's changes and tell the other person to start from scratch.
If you are in an environment where large amounts of data access are happening and your team is using DBML, you will be constantly changing this file and having merging problems.
Because of this quirk in VS2010, I have seen a team implement a rule "Whoever checks in their code first wins during a merge conflict". The result of this rule is that developers end up checking in often and in smaller batches to ensure their work remains the "keeper" during a DBML merge.
What I find intriguing is that this quirk is inadvertently changing the habits of .NET developers who used distributed repositories to check in their code on a more regular basis.
Jenkins - http://jenkins-ci.org/
Cruise Control - http://cruisecontrol.sourceforge.net/
Team City - http://www.jetbrains.com/teamcity/
Bamboo - http://www.atlassian.com/software/bamboo/overview
DBML Format - http://msdn.microsoft.com/en-us/library/bb882675.aspx