Stuart provided some great feedback on his experiences with VS 2002/2003 and SourceSafe. Since I’ve talked to some co-workers to find some of these answers, and since it’s kind of long-ish, the response has been promoted to its own post. Read his feedback first for more context, but this post should stand alone fine as well 🙂
Hatteras (the code name for the source control component of Visual Studio Team System Team Foundation System – I think that’s about the right term) is actually written fully from scratch. There’s basically nothing shared with the SourceSafe group outside of some people (check Brian’s information post).
I’ve talked with
This works great for VS+Hatteras (we pend renames/deletes as needed) and should actually work fine with VS2005 + SourceSafe 2005 where a dialog will prompt you for whether you want to propagate the change to the server.
I may be misunderstanding the situation, but you specifically mention “overwritten on next ‘Get Latest'”. Because of this, you’re talking (I presume) about a local file being modified that was fetched from source control. When Hatteras fetches the file from source control, we make the file read-only by default. Only when you decide you intentionally want to make changes do we pend an edit on the file. In the normal VS case (you opened the file from solution explorer or something like that), the default is “checkout on edit” so when you start editing the file, we’ll automatically pend an edit (check it out from Hatteras). Then, it’s like any other pended edit – if someone checks in a later version, that’s a conflict that you need to resolve, and our resolve capabilities work great (accept mine, accept theirs, automatic merge, manual merge, etc.). However, if the user cuts-and-pastes or similar, VS is just going to have a buffer with some contents in it and doesn’t “know” it’s the same file (again, I may be misunderstanding the situation you’re describing, though). If you go to save on top of one of your source-controlled files, it’ll be readonly and that will fail – you’ll have to explicitly check the file out. Once you check the file out, it’s a regular old pended edit and everything works as you would expect. Please feel free to elaborate if I misunderstood your situation or if there’s anything I can do to better explain our behavior here.
Hatteras has no such magic string in our project files. Almost everything is local-relative-path so as long as you’re doing branch/merge operations above your solution directory, you shouldn’t even need any changes in the .sln/.*proj files. Branch/merge work inside solutions as well, but I’m personally one to recommend people have structures like $/project/trunk/solution/projects/ and then “h branch trunk rel-1.0” and the like above the solution directory.
Hatteras merging is very intelligent – changes already merged won’t be merged again, and you can merge at the project level just fine – merge from one directory to another is implicitly recursive, so we merge the full contents. From the previous item, if I created my rel-1.0 via “h branch trunk rel-1.0” then I make changes to rel-1.0 that need forward-porting, I can just “h merge rel-1.0 trunk” (you can merge in either direction of the branch, so you can merge to back-port changes to rel-1.0 as well). If I make some more changes to rel-1.0, I can re-execute the same merge command and it’ll only merge changes since the last merge (it keeps a merge history, and won’t re-merge things already merged). You can “cherry pick” changes – if changesets 130 through 140 were all on trunk, but I need to only merge the changes from 135, 136, and 137 to rel-1.0, I can “h merge /version:C135~C137 trunk rel-1.0”. You can even use /discard to make sure certain changes never propagate, like if changeset 139 should never be merged to rel-1.0, “h merge /discard /version:C139~C139 trunk rel-1.0”
We’re trying very hard to make sure we do the right thing for renames, branches, merges, and the like. We have all had to deal with the pain of source control systems that didn’t make those kinds of workflow easier on us, but those should hopefully be a thing of the past with VSTS and our source control.
Thanks again to Stuart for such great feedback!