> Making files readonly is also silly: it doesn't > prevent anything (you can make the file non-readonly with a simple command) > yet it is annoying when you want to alter some files.
What it DOES is give you a chance to handle the model where you _do_ want exclusive locks by creating an event-point to check for that in the repository. It also lets quick scanning by a simple attribute. > odd, as SVN is able to get this change and will commit it. > As long as the folder / file is in the repository of course. But > if it isn't, it's not part of the reality in the central storage so > nothing has to be checked anyway. There one thing in TFS that is better than SVN for this... when you add a new file to a project, the IDE automatically pends a "add" operation on that file, which allows it to handle the multiple programer, random commit order a little better in places that do want exclusive locks. > > 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. > > that's also true for SVN: you can't commit to revision 10 (your version) > if you do a commit against HEAD and the HEAD is > revision 11. That's where TFS is better, to me. It does the update, but when it does that it really handles all the files in the same change-set (e.g. everything committed at the revision between what I had and current HEAD). This insures that I have a buildable system with ONLY the changes I need, not the complete HEAD. > > chosen at the baseless-merge time. It's awesome. > > something like the switch command in SVN, so one of the persons in > the example uses switch to switch over to the folder of > hte other for that folder? Not sure about that SVN feature, but what baseless merge lets me do is carry TWO (or more) branches from ONE tree by splicing two seperate trunks together after any amount of individual growth. After that point, the two act like the same file with multiple branches (with the attendant space savings, merge features, etc) I'm also really fond of the shelve-set features of TFS... lets you write entire chunks, shelf them and later come back to work on them some more (just commit them). During the time you are shelved, you can work on other branches or the trunk IN THE SAME working folder set. When you unshelf, you get popped back to your original state with an (optional) update to current tips. It even manages multiple shelve-sets. I'm using this for feature-complete checkins... then the code reviewer can unshelve and commit to the trunk any feature set they want :) -- "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
