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 (7)
  1. Stuart says:

    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?

  2. Ah, Stuart, thanks for the great description of the behavior you were seeing with drag-drop/cut-paste. I’m going to check into this tomorrow to confirm we’re indeed fine, but my experience with VS Whidbey has been that it treats 1) source controlled files and 2) read-only files correctly. Note that for files fetched from Hatteras, both of those conditions hold, so things should behave fine, but I’ll check to make sure and reply again on this post.

    Glad to hear the other answers are what you wanted to hear – we really are trying to make the user experience "do the right thing" – hopefully we’ll get pretty close 🙂

    In terms of SourceSafe and our source control (VSTS Team Foundation – the marketing people will smack me around I’m sure), there’s no shared code and no connection between SourceSafe and any part of VSTS. SourceSafe has been a long-standing product from Microsoft and will continue to be so in the future. It is its own product. VSTS is an entirely new stack of software, obviously to compete mainly against similar stacks of software that also try to tightly integrate the software development experience (Rational et al.) SourceSafe has no connection to VSTS – it’s not the source control component in VSTS and can’t be.

    VSTS has lots of components (work item tracking, source control, requirements gathering, etc.) but the Team System shines mainly because of all the integration between the components. This has been focused on a lot in the "why no unit testing in the base VS2005?" kinds of discussions especially – it’s not about any single component, we’ve design and implemented an entire system where the real value isn’t just the components, its the entire system working in concert – and it’s a thing of beauty IMHO 🙂

  3. Stuart says:

    Hmm… Will VSTSTF (I think it should be the marketing people being smacked around for that name, btw 😉 ) have an importer for VSS repositories?

    I wonder if the corner case we were hitting with VS2002 was perhaps that the files had somehow got marked writable on disk, despite still being checked in. For example, if the file that’s being pasted in from the filesystem is writable, might that have overwritten the readonly attribute and caused VS to get confused? Have you considered cases where the readonlyness of the files doesn’t match what Hatteras expects it to be?

    I posted a comment like this before in someone else’s blog, but I can’t get over how great the "new, transparent Microsoft" is. Full disclosure: I’ve not always been the biggest MS fan and I tend to identify more with the Open Source community in general, but since I use MS software for my job, I’m VERY happy to see the way that things are improving over there – both technically and "socially", as it were. Being able to post a comment on a blog somewhere and get a high-quality and timely response from someone involved in a major way in developing the software itself is something you’d expect from Open Source, but getting that kind of response from Microsoft is quite a revelation – or maybe a revolution? 🙂

    That’s a little off-topic, perhaps, but I figure a bit of gushing praise never goes amiss 🙂

  4. Kiliman says:

    WRT Item 3: You can get the VSS Magic String of a source controlled item using the undocumented command "PHYSICAL". For example:


    Will return "AAAAAAAA"

    Hope this helps.

  5. 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 🙂

  6. Stuart says:

    Kiliman: Congratulations, you just got 3/4 of our developer team[1] saying "Holy crap, that’s COOL!". In one way that’s a little sad that we’re so excited for a workaround to a problem that never needed to exist in the first place, but you just saved us a ten or fifteen minute process every time we create a new project, so THANK YOU!


    [1] Okay, it’s a 4-person developer team…

Comments are closed.

Skip to main content