When working in a large software development team, whether you have many developers working on the same projects, or your project is linked to other projects; it is very important that developers regularly perform "get latest" to ensure that the changes applied by their team mates are included in their workspace.
Although Team Foundation Server 2008 & Visual studio 2008 offer a feature to get latest on checkout, sometimes in larger development teams, there is a need to always ensure the workspaces are most updated all the time.
The below solution helped achieve this within our team, since you can not always rely on the developers' memory / discipline to perform get latest manually.
-Create a new text document with the below text
@echo off
CD D:\Development_application
s
"%PROGRAMFILES%\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" get
Exit
Where D:\development applications is your workspace folder , change it to your actual workspace.
Save the file as GET.bat in the root of your C drive or wherever you wish.
Open Command Prompt (CMD).
Type the below command.
Schtasks /Create /SC Onidle /I 5 /TN GET /TR C:\get.bat
Enter your Domain account password when prompted into CMD window.
This will create a scheduled task that runs when the computer is idle for 5 minutes (not in use). This will enforce get latest from Team foundation server source control and ensure your workspace is always updated.
You can also edit the scheduled task directly from Control Panel > Scheduled tasks later on to schedule it on different times that suit your schedule (at night , on login / log off ,etc..).
Another thing to consider is to regularly update the password in the scheduled task whenever your domain password changes. This is necessary to avoid running this scheduled task with a wrong Password, which may cause your Domain account to get locked out.
Hope this helps you as much as it helped me .
Comments (5)
Commented:
Author
Commented:Also the above example will prompt you in case of any conflicts between your workspace version & the server version, it can be suppressed by accepting a particular version in the command parameters, but I think it is best to leave the option to the developer to resolve such conflicts.
Commented:
IMOa better solution is to always update just prior to a check in and ensure all code still builds and all unit tests still run. Then, have all code get checked in via a integration server, which will clean build code with ONLY your change, run all unit tests and only commit to the source control system if it passes. If it fails reject it.
Arbitrary updates when you're in the middle of working on things are only likely to cause more problems than they solve. I would, certainly, not subscribe to or recommend this as a practice.
Author
Commented:Development environments differ, what does not suit your team, hits the spot for another.
I am also well aware that developers' discipline is quite different from the SCM, developers prefer to have everything customizable and left to their own judgment.
SCM is more inclined towards automation,avoiding unneeded problems like (human error, build breaks, code instability,release delays , etc..), especially if you work on delivering mission critical systems where delays or errors are not acceptable.
Author
Commented:Works like a charm.