WRT Stuart's excellent questions
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 Ben Ryan (he does most of our VS integration work) and Bill Tutt (server-side merge engine) and from those conversations:
Item 1
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.
Item 2
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.
Item 3
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.
Item 4
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!
Comments
- Anonymous
July 12, 2004
Thanks for the great responses :)
WRT item 2, the problem in 2002 (I haven't seen it specifically in 2003 but everyone here has been trained in avoiding the situations that caused it, so it may or may not still exist as a problem there) was that while it seemed to try to enforce the rules as you stated them (always check out when you're going to edit something) there seemed to be some actions where it wouldn't notice that you were overwriting a source-controlled file. I can't remember exactly the sequence of actions that caused the problem, but it involved either drag-n-drop or cut-n-paste of files from Windows Explorer into the VS solution view. Sometimes this operation would "succeed" even though the files in question already existed in the solution and were checked in to source control; the copy would simply overwrite the local file without notifying SourceSafe at all.
WRT all your other answers, they're exactly what I hoped to hear and I can't wait to use this system :)
WRT the relationship between SourceSafe and VSTSFS(?), where does SourceSafe 2005 fit in? Is that the old code worked over, or the new code cut down and repackaged? - Anonymous
July 12, 2004
The comment has been removed - Anonymous
July 12, 2004
The comment has been removed - Anonymous
July 13, 2004
WRT Item 3: You can get the VSS Magic String of a source controlled item using the undocumented command "PHYSICAL". For example:
SS PHYSICAL $/
Will return "AAAAAAAA"
Hope this helps. - Anonymous
July 13, 2004
The technical questions just got their own post :)
A lot of our PM's kind of hate the "now Microsoft interacts with customers!" bit because a lot of their job has always been both working with and interacting with customers - unfortunately, it wasn't as public as these blogs are now, so it didn't get much general exposure.
I can understand your Open Source explanation - I've done open source work at my last 3 jobs, including Linux kernel development while doing performance work at IBM - I loved the communities that built up around some of the projects (not all of them) because it was largely a meritocracy where your opinions and ideas mattered in relation to how much you were really willing to contribute to the project - people sitting on the sidelines and whining don't matter, real discussions by the people working on and with the project did.
Until I joined Microsoft, I didn't realize that the same kinds of communities existed inside Microsoft at all - it was hard to really understand what life at Microsoft was like from the outside. Now that I'm here, I'm finding that all the same things I loved about those open source communities are alive and well in the Microsoft world and have been, they've just been more cut-off from public exposure.
In that vein, the blogs and other methods that we're doing to help expose these great development communities outside of the company are very exciting and a definite advantage to our customers. I myself definitely spend hours each night reading the blogs of some other great MSFT people like Raymond Chen, Christopher Brumme, Brad Abrams, Duncan Mackenzie, Eric Gunnerson, etc. etc. etc.
Glad to hear I'm helping out in some small way - and glad to hear your excitement about the new system! We really feel it'll be a home run for our customers :) - Anonymous
July 13, 2004
The comment has been removed