Designing and Organizing Projects

VSS does not impose project design criteria. However, to ensure that your project is organized carefully and runs efficiently, consider the following design guidelines:

• You may want to make each existing folder in your operating system a project in VSS. Each subfolder can be a subproject. For example, if you store code in a folder with three subfolders in your operating system folder, create a project with three subprojects within VSS.
  
  
• Divide files logically among projects and subprojects. VSS 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 separately to multiple projects if you want the same changes to be applied to 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.
  
  
• Place all the files necessary to build one program in one VSS project. Such files are generally code but can also include makefiles, libraries, bitmaps, dynamic-link libraries, and even subsidiary programs.
  
  
• Don't keep executable files in VSS projects unless they take a long time to build. Don't take up space in VSS 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 VSS 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 VSS 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.
  
  
• When you nest subprojects, observe the supported limit of 15 levels of nesting. This may also be restricted by the project path string length of 259 characters.