C# Rocks

Why Java Sucks and C# Rocks (Final) from jeffz

A Professional GROUP 4 DotNet Leads & Architects

A Professional GROUP 4 DotNet Leads & Architects http://www.linkedin.com/groups/DotNet-Leads-Architects-4672882?goback=%2Egin_4672882_true_im*5invite_cs*5connections%2Eanp_4672882_1350328357277_1 …

Steps: Check-in/Check-Out Mechanism for TFS - To avoid Build errors and improve Productivity

You all may be already aware of TFS and its usage to effectively work as a Team on a Team Project but I thought to reassemble some of the important points/steps to ensure good Productivity (by avoiding Build errors as much as possible).

So please read the below points and also add your feedback by adding your comments to make this more informative (This would really help especially if 'Multiple Checkout' option is Enabled):

1.      Always make it a practice to Get the latest version of the Project daily morning before you start your work.

2.      Build/Rebuild your Solution to ensure that there are no build errors.

                  -->If you get any build errors, check what are those. Suppose if they are simple to resolve like 'Broken Reference' errors or any other                              simple errors please take initiative and resolve them. If you notice that they belong to some other Team member's task please                                  intimate him/her so that they could fix it.

3.      Check out the file(s), which are relevant to your task and start working. Once you are done with your work, verify it by building the project. And          if you don't find any build errors; run the project and test your page whether it is working fine. If its fine, check in your files. If you find any build          errors or runtime issues then resolve them and then check in.

                  --> It's always a good Practice to divide a big Task in smaller tasks and on each sub task's success you can check in your work. For example UI design, populating dropdowns, placing validations, saving form data, displaying grid data, etc can all be treated as individual sub tasks for a particular page functionality. This will ensure that you will not have any pending check ins at the end of the day and also it keeps things easy. If a sub task is taking a longer time and if you want to continue it the next day, you can comment your partial written code and check in the file. The next time you start work you can checkout, uncomment your code and start working. This practice will minimize the usual conflicts we get when we are working under 'Multiple checkout' option enabled and also it will not have any impact if TFS connectivity issue occurs.

4.      Sometimes when we take latest version from TFS we get some conflicts in some files, check these conflicts carefully and if the files don't belong to you, you can straightaway choose the option 'Resolve Conflicts'. Then VS/TFS takes care to automatically resolve conflicts for you. And if a file belongs to you on which you recently worked on then most of the times you have to choose 'Auto Merge' option so that your changes and the last guy who has checked in recently, his changes, would be automatically merged and saved to TFS. And still if you feel you have to cross verify the changes, you can trace them in 'Merge Tool' option and then merge it.

5.      Till now the check in and check out process what we discuss is for the existing files in our project but there is a slight difference in case of adding a new file, renaming a file, deleting a file. As TFS and your project are already have metadata reference/info of your existing files, hence it only checkouts the file when you start making any changes or if you explicitly check out it but it will not checkout your project. 

But in case of adding a new file, renaming a file, or deleting a file the TFS and project will not have this reference in .csproj file and source control .vss file or it might need to update the metadata info of that file; hence it checks out the Project as well whenever this kind of operation happens on a particular file. If you are familiar with File system and file handlers it would be much easy to understand this TFS behavior. Now you need as usual build and run your project, verify and then check in the pending items (file plus project).

This practice as well minimizes the possibility of getting conflicts and therefore makes things much simpler and in our control.

Finally our objective should be to simplify our work and avoid confusions and also make sure to avoid error-prone check ins. (Note that a small mistake from an incorrect check in could create lot of build errors for other team members hence affecting their productivity).

Your inputs, clarifications, and feedback in this regard would be highly appreciable.

Thanks.