We are planning our release process at my company and will be using Visual SourceSafe. A friend of mine suggested creating three separate directory trees in VSS. One for Development, one for QA and one for Production. Is this what you are doing at your company? Mainly, I was wondering if it's possible to set up the user permissions in VSS so that, for example, developers can check in or out code within their "tree", qa can check in or out of the qa tree, but can only check out code from the development tree. Finally, operations (the team that would pull the production code) could check out code from the production "tree", but qa could check in or out code within the production tree.
A programmer at my company said that he thinks this is a bad idea. He suggests just using one tree and just use labeling to differentiate the development, qa and production code. But I don't know if you can control check in/out by just labeling. Fairly certain, although I haven't really used VSS, that it wouldn't be possible.
Feedback from the VSS experts out there would be much appreciated.
I can tell u the advantage of VSS.
If u keep your files in Vss if by chance though u lost the files u can see it in vss.
we can identify who are the people check out the files. by their sysytem it will be noted there once u check in the name will be removed.
u can give permission so that other people will not able to access it.
From my experience, one of the biggest advantages of VSS is "labeling". You can label your code at one stage and the production team can used it, or the QA team test, while the development team keeps on working.
It really depends on how your development cycle is, but we've found VSS pretty practical for our pourposes.
One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say.
They used the 3 tree structure at my last company, and I felt it worked great. The individual test team members did not have the ability to transfer files, the development team manager and Test team manager did. Thus, when development was ready for test team to test their code, they would move it over to the test area. We could then do a build using that code, and do regression, system and integration testing on it. If it passed (normally after the 3rd or 4th try), then we'd notify the test manager that it could be moved to the production server.