Answers to Your SourceSafe Questions

An email arrived in my Inbox recently from a customer that read,

“I've got ALOT of questions, and I hope you could help me...

  1. How do I use Shadowing in .NET?

  2. How can I force users to check in their files and log out of SourceSafe so that I could lock the DB?

  3. How can I split a DB?

Help needed ASAP please!  Thanks dearly!”

Dude, you came to the right place. 

In general, if you have questions about Visual SourceSafe, you can see everything I've ever published on the subject in my blog by clicking the Visual SourceSafe category on the right hand side of my blog page. On the page that appears, scroll to the bottom of the main frame and click Full Visual SourceSafe Archive.

For answers to your questions:

  1. How do I use Shadowing in .NET?
    See, SourceSafe Shadow Folders, Maintaining Synchronicity.

  2. How can I force users to check in their files and log out of SourceSafe so that I could lock the DB?
    See, End-to-End Analyze Script for Keeping a VSS Database Healthy (user ejection seat not included).

  3. How can I split a DB?
    See, How To: Split a VSS Database into Two or More Databases

This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen. Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.

Comments (17)

  1. Henry says:

    Question: does microsoft use vss for source control? it doesn’t seem to be able to handle large loads of programmers

  2. A curious lurker says:

    We’re using VSS on a project and were wondering how VSS decides if a file is binary or not? If it asks Windows, do you happen to know how Windows decides this?

  3. Charlie Hensler says:

    Hi Korby.

    I have a question re the solution root folder:

    I recently set up a build/source control environment for client – new to both .NET and VSS (and source control in general).

    I based my approach on the Team Development whitepapers on MSDN (I wanted as standard an approach as I could get), and prior experience at Microsoft.

    Unfortunately, I was using VSS 6.0c and, for this reason (I think) the "solution.root" functionality wasn’t apparent. My clients, of course, have fresh installs of VS 2003 and VSS 6.0d.

    Now the question is whether I should revise the entire approach to work with the default solution root behavior, or recommend turning it off.

    I’m leaning toward the latter because it still seems like a better approach to me to start with a blank solution, and create a symmetrical folder structure on the dev machine, in SourceSafe, and – in our case – on the build server as well.

    Our current approach – which is right out of the MSDN whitepapers – overrides default Visual Studio behavior that occurs when you create a new web application – we create the vdir ahead of time, and force the project files on the dev machine into the shared, symmetrical folder structure. It doesn’t appear that the root folder approach accomplishes this?

    What do you think?

  4. Charlie–Your clients hired the right guy. 🙂 The solution.root feature forces the working copies of all solution items into a cone (my team calls this ‘coneness’, which drives me crazy b/c conicity is a word but ‘conness’ is not).

    Anyway, I only advise that you turn off the solution.root feature if your client is very process-oriented. If they operate in a more adhoc manner, you should only turn it off if you think you might be looking for consulting hours in a year or two, because it could lead to some…um…challenging source control issues.

    In "The .ROOT Folder and "Unified Root"" [1], I respond to this very question. Here’s an excerpt:

    "I’ve heard a few academic complaints that the creation of the SolutionName.root folder conflicts with the guidance offered in our Team Development Guide and the whitepaper that Martyn Lovell and I wrote a while back. Technically, this is true. In reality however, this feature change is perfectly congruent with that advice and indeed, maintains an SCC folder structure that mirrors what you see in Solution Explorer. Thus, I would more readily advise you to revise your build process slightly than turn off the creation of the .ROOT folder. In fact, I plan to suggest that the tool (which is based on the Team Development Guide) be updated to accomodate the .ROOT feature. Nevertheless, I’m not one to hold back information unless I absolutely must. So here it is. You can turn off this feature in VS.NET 2003 using the following procedure:"

    Other related posts include:

    "Guidance on Creating Projects and Solutions" [2]

    "Best Practices for Setting up Source-Controlled Solutions that Contain Web Projects" [3]




  5. Charlie Hensler says:

    Well – I guess its arguable that they could have looked for someone with more, uh, coneness. I mean conicity.

    So the problem the .root folder is solving is that, when adding a solution to source control, Visual Studio will automatically arrange all projects in a multiproject solution under the .root folder in VSS – without involving the user (except for specifying the initial solution location in VSS).

    This is essentially what we’re doing now – except that dev must specify the location for the solution, and then for each project under the solution as well.

    But, the .root functionality doesn’t have anything to do with maintaining a symmetrical folder structure between VSS and the dev machine – web applications are still created by default under wwwroot – even though the solution file and files for other project types are likely to be somewhere else.

    So…with the .root approach you are more or less saying local dev machine project locations be damned, when submitted to source control, all projects will be arranged in a predictable way under the .root folder – happy and well organized in their, uh, cone…

  6. Nicolas says:

    Can I rollback a entire project to a specific label? It seem the rollback only work on one file.

    Ok I can use the trick: checkout, delete, get old version, check-in. But the history (and comment) are not updated.


  7. Sanjeet says:

    Is it possible in Visual Studio.NET to hook up to two or more projects from separate source safe databases in one solution file ?

  8. Mallio says:

    Is anyone aware of a utility out there that can check VSS files in and out through the Windows Explorer? We have some files controlled by VSS but not wrapped up within a project and traversing the project tree in VSS’ IDE is time consuming. It would be nice to be able to right-click a file and check-in/out for quicker access. Thanks for any pointers…

  9. They do exist. Some are in active development. All are third party projects. They’re often referred to as namespace extensions. When WinFS ships, Windows Explorer-based file versioning will be truly possible. IMHHHO, the existing implementations I’ve used are somewhat kludgey and hacked together.

    Can somebody out there point to one or two?

  10. Steve says:

    I am new at a company and one of my projects is to enhance an application we wrote to interface VSS 6.0 with an internal bug tracking system. I am working on some parts to check for conflicts when we go to pin certain versions. We use pins to control which version will be played into our production DB. The question I have is how do I find out which version of a file is pinned? I can look in VSS and see which file is pinned, but from VB or command line I have been unable to find any direct way with the VSS Object Model to tell which version of a file is pinned. Does anyone know how VSS keeps track of this? Is there a file used by VSS that keeps track of all the file names and the version that is pinned? If you think you have an answer to this please let me know or email me



  11. mirela says:

    Very nice blog. It is very helpful.

  12. Payday Loan says:

    Very nice and informative website.

  13. Katrina says:

    Very nice website with a lot of informative response from members

  14. Himn says:

    I like this blog.

  15. maheshgv says:

    We are planning to use SS2005 for these operations.

    We are having a different model of development. We have a product (solution) which will be the base code for everyone. When we install the product to a customer, we are planning on creating a new solution named after the customer. All the solution files from the base will be shared with the customer solution. At times, we’ll be making some custom changes which are exclusive to a customer. At this time, we want to branch the required files to the customer solution. Now, my questions are

    1. When we fix an issue in the base code, how can it be rolled out to all the customer solutions?

    2. When we want to upgrade the product (new release), should we create a new solution all together or just label the current build before making new changes?

    3. Will we be able to use VS2003 based solutions in SS2005?

Skip to main content