I'll never forget the first time I had to set up a file server for a small company (four employees). This company was new to the idea of shared storage-a file server that everyone could access. They were accustomed to (and pretty happy with) the "sneakernet," and weren't sure they needed an evil network. But they trusted me, so they were taking the plunge, brave souls.
We had a meeting to discuss how the folders should be organized, and the discussion quickly bogged down. Everyone had a different idea of how it should be. Every suggestion struck everyone else as confusing or hard to use. We ended up deciding on something, of course. But it was clouded by the ugliness of not being quite right for the majority, along with the knowledge that it would always be an awful compromise.
I raise this problem of network folder rigidity to contrast it with the way Visual SourceSafe (VSS) makes this problem go away. VSS doesn't have the same architecture file systems do. All-or-nothing decisions about "where to put things" are not necessary. In VSS, you have the freedom to organize things in ways that make sense to everyone.
In this article, I'll explain how to use VSS Shares to ensure that everyone can find-and work on-their files, not just the person who set it up. You probably won't be able to please everybody, but you can probably come close.
What is a VSS Share?
I'm assuming you already know that VSS organizes its files in a hierarchical folder structure, much like the Windows file system. So, if you're a development shop and you keep your code in VSS, you might set up VSS like illustrated in Figure A:
In VSS parlance, that "Source" thing is a project. Most people I know call it a folder, since it looks like the things you see in Windows Explorer and it is organized hierarchically, but the creators of VSS conceived it as a repository of a software project, so that's the terminology you see in the UI and in the Help.
Conceptually, a VSS project is not really a folder, it's a Share. A Share is a ghost folder. It's not a real folder at all; it's just a pointer to a set of files. That is, VSS doesn't have its own internal file system, nor does it organize things the way Windows does. VSS has its own way of keeping track of its files, and using literal folders is not it.
That's where the flexibility comes in.
Let's say you have an employee who manages client relationships. This person serves as your product manager and client services manager. As such, this person needs to share product documentation with clients and prospective clients. That means their work and all of their thinking is oriented toward clients, not source code.
For them, in terms of the files to which they need access, the only thing that matters inside your Source folder is the Users Guides. They don't care about the source code or the solutions organized into projects and the deep layers of inscrutability you've built into them. All they care about are the Users Guides.
This person needs something more suitable to their needs, like Figure B shows:
Now your client services manager has a Client Services project, with a sub-project for the Users Guides. But your developers have their Users Guides with the software projects shown here:
The good news is that you don't have to choose which one of them gets to house the Users Guides. All you have to do is use VSS Shares. With VSS Shares, both of them can have access to the same documents, but from their own data stores.
The process of creating Shares is very easy, but not very intuitive. First you identify where you want to put a copy, and then go get the copy. Here's how to do it:
1. Locate the project that needs, but does not have, a copy of the file you want. In this case, that's the client services manager's Users Guides folder. Right-click that project and select the Share to option, as shown in Figure D:
You will get a Share to dialog box. 2. In the Share to dialog, navigate to the folder that contains the files you want to get, and select them:
The Branch after share checkbox determines whether you create another copy of the file, or just create a pointer to it. For purposes of this discussion, leave that checkbox cleared.
3. Click Share. The documents you selected will disappear from the list:
The documents you selected have disappeared from the list not because you have moved them, but because you've already shared them with the location from which you started this operation. There's no point in sharing them again.
4. Click Close. VSS returns you to the location from which you started, this time with the documents you shared listed:
Notice the little arrow in the lower-left corner of the document icon. That's an indication that the document has a pointer in more than just this project. In fact, if you navigate back to the original, you'll see the same modified document icon next to the document name:
What have we done here? We've created two locations for the Hello World Users Guide-one that makes sense for the developers, and one that makes sense for the client services managers. And if we needed to, we could create even more locations, each one tailored to the needs of the people who need access to it.
Because of the way VSS stores files, you have great flexibility in how you organize a VSS database. You are not bound by the same limitations placed on you by the Windows file system. You can create hierarchical structures that serve the needs of the various roles in your organization, with no need to remember who owns the home location for any of the files. This feature alone makes it a good solution to the problem of how to make shared files accessible to everyone.