> what I always hated with VCC based sourcecontrol packages was: > - they make files readonly on disk > - they pollute vs.net project and solution files with garbage which will > cause havok when you open it on another system. > > Does TFS also lock files on disk and pollute your solution files with > VCC crap? Or is that optional and can they also do the > edit/checkin pattern?
The files are read-only on disk so that you don't fiddle with them without "pending a change". This does NOT lock the file, just notifies TFS that the specific version that you have "previously gotten" has a possible pending change. Later, when you commit everything it knows what files to examine (not based on the read-only bit being off, but based on the notification it got). This means that HUGE directory trees are not scanned for check-in, rather the possible set of files is known.This does mean that you could (outside whatever too, be it the IDE integration or the command-line stuff) clear the read-only bit and fiddle the file and it would never get checked. This is mitigated by occasionally doing a get-latest which will detect the files has been touched, pend a change and ask you to merge (or do so automatically). This is also how offline changes are handled (i.e. when the TFS server is inaccessible). As for the cycle, this is VERY close to the edit/merge/commit model of SVN, except you always are assumed to be commiting against the the verion that you pended the edit against. This means that if someone else did changes after you pended your edit, you get the option to merge or branch then. The locks are optional (you can request that nobody can pend edits, or you can request that nobody can check-in, OR you can request no lock at all). There are some REALLY great blogs about this, start with Buck Hodges' at http://blogs.msdn.com/buckh The latest cool feature is that you can do baseless merges, which is where you and I are working on two project and sharing a (say third-party) library. After a while, we both realize that the other is using that library and making changes... we can tell TFS that they both are the same and it lets us merge them EVEN in the absence of a common root version. Once that happens, the delta are maintain against the common trunk chosen at the baseless-merge time. It's awesome. Regarding your VCC corruption... the IDE integration requires some sore of tracking for the IDE, but the TFS doesn't need it per-se if you are doing thing from the SCC explorer or command-line only. That said, they did a really nice job for everything exept the projectless web site (which sucks in so many other ways that I can't blame TFS for having issues). -- "Under capitalism, man exploits man. Under communism, it's just the opposite." –John Kenneth Gailbraith Marc C. Brooks mailto:[EMAIL PROTECTED] http://musingmarc.blogspot.com
