I admit, my TFS blogging has slowed in recent weeks. We're right in the middle of our largest migrations and so I've been spending more time doing work, then telling you about my work. Anyway, today's posting is about removing files from the file system outside of Teamprise Explorer or Team Explorer.
While I don't keep count, I'm guessing ten or so people have stopped by my desk asking why the "Get Latest Version" does not work. At first I freaked out and thought we'd implemented a product developers couldn’t' use, but then found it was simply a circumventing issue.
99.9% of the time when people have this problem it goes as so. They first setup of their workspaces and get the code, but since they're new to TFS, they typically setup the workspace not to there liking (e.g. $/ --> c:\development) and do a Get. This results in a lengthy Get of all the code we have.
To correct this, they first delete the code locally. That is; they open My Computer and delete c:\development \*.*. They don't want all that code filling up there 100 gig hard drives (insert smile here).
After the full delete finishes (it usually takes most of the lunch hour given they just pulled five million lines of code locally), they return to Teamprise Explorer or Team Explorer and try to do a Get just on the projects they need (e.g. $/MyProject/MyApp). Unfortunately TFS says "All Files are up to date" and won't allow them to Get files. This is when they call me, the administrator.
I simply fix their issue by having them do a Specific Version Get and Force it to pull the files down locally. To be honest, the message they get says this as well, but for some reason humans avoid reading messages. To prove that, just two days ago a developer asked me how to resolve the check-in policy error "Please provide some comments about your check-in" (insert second smile here).
So I'm not sure what the ideal solution is, but I'm wondering if TFS ever could be so smart as to first look at the file system before it says "All Files are up to date." This would add overhead, but might save overworked administrators some headaches.
Friday, August 31, 2007
When "All Files are NOT up to date"
Subscribe to:
Post Comments (Atom)
2 comments:
There is good reason for this; it's called performance. Apparently you never used Source Safe. That is exactly what Source Safe did. It was convenient in that Get latest really got latest and replaced files on your workstation by either date differences or checksum value. However, the reason no one does this anymore is that it is very expensive when donwloading large projects, and it has a very serious impact on remotely connected users. This is one of the chief complaints about Source Safe and why TFS uses the new methodology. TFS, Perforce, Source Gear Vault, and others use a method of logical cache at the server level of "what you have on your client workstation" by workspace. They check that and report back what is different from the matching sorce controlled files. Perforce provides a validataion function that will check files, directories, entire projects, ... for file differences by the older and slower method from server to client, but it's a manual operation for the user to use as a sanity check and not a normal fetch mechanism because of the time it takes to complete. TFS currently does NOT provide this type of validation call (that I know of and I have not used the 2008 version that's now available.) and I hope that it's added soon so that your users and myself can validate their install. One more thing, if the users remove from client using the interface (selecting the special changeset #1 on a get specifc) rather than deleting files from the drive directly, they may be happier. These file download caches rely on this to work correctly. Even if they blow away the directories manually, the user can still just right click on the project and selct Get Specific Version. Then from the dialog select Type: Chaneset and ChangeSet: 1. This will remove all files for that project from the drive and the server cache. Now if I could only Get TFS to donwload files with the date of the file at check-in.
Thanks for the feedback mkmcgregor. We actually did use Source Safe and are in agreement on the performance problems.
I can see where the logic to do a local check would add a large amount of overhead. And to be honest, once we trained the users to do the Get Changeset 1 (like you have also suggested) the users are pretty well trained.
Thanks again for the detailed feedback. I appreciate your insight.
Post a Comment