Designing Projects for Your Team

  • Article

Visual SourceSafe does not impose project design criteria. However, to ensure that your Visual SourceSafe project is organized carefully and runs efficiently, you might want to consider the project design guidelines described in this section. When you are ready to create your projects, see How to: Create a Visual SourceSafe Project.

General Project Design Guidelines

You can apply the following project design guidelines to any type of Visual SourceSafe project:

  • You might want to make each existing folder in your local file system a Visual SourceSafe project. Each subfolder can be a subproject. For example, if you store code in a folder with three subfolders in your local file system folder, create a project with three subprojects within Visual SourceSafe.

  • Divide files logically among projects and subprojects. Visual SourceSafe handles up to 8,000 files in a project, but breaking large projects into subprojects makes files easier to manage.

  • Don't add the same file to multiple projects if you want file changes to be applied in the separate projects. Instead, share the file among projects.

  • Don't create a new project if you are simply moving to a new version of a project. You can label the project to mark the version.

  • When you nest subprojects, observe the supported limit of 15 levels of nesting. Subproject nesting might also be restricted by the project path string length of 259 characters.

  • Remember that all subprojects in a project must have unique names. Within each project, file names must be unique.

  • When naming your projects, use Visual SourceSafe's naming conventions, as defined in Naming and Syntax Conventions, and Size Limitations. File and project names are not case-sensitive. For example, if you have a file named Test.C, you cannot create a subproject or file named "Test.c" or "test.c" in the same project.

Project Design Guidelines for a Development Environment

If you are setting up projects for a software development environment, you might want to consider the following development project design criteria:

  • Place all files necessary to build one program in one Visual SourceSafe project. These files include code files, makefiles, libraries, bitmaps, dynamic-link libraries, and even subsidiary programs.

  • Don't keep executable files in Visual SourceSafe projects unless they take a long time to build. Don't take up space in Visual SourceSafe when you can compile and link to build an executable file on demand.

  • Ensure that the project only contains the latest tested code that compiles and runs. While this is sometimes not possible, especially at the inception of a project, a good rule of thumb is that nobody should check code into Visual SourceSafe unless it compiles and runs. If this rule is followed, anyone can get a project, compile it, and see the state of the project at any time.

  • Store your current documentation files, icons, graphics files, and other files in Visual SourceSafe projects.

  • In any multi-user project, no file should be checked out for longer than it takes to make and test the changes to the file. If a file is checked out for several days, other people may not be able to use the most current version containing the changes that have been made to the file.

See Also

Tasks

How to: Create a Visual SourceSafe Project

Concepts

Files and Projects in Visual SourceSafe
Naming and Syntax Conventions, and Size Limitations