Best Practices for New Repository, Source Tree

[Michael_Dorfman]

I'm thinking of creating a new repository, and am looking for some Best Practices.

Here's some background: Right now, we've got a large repository holding all of our source code, and a fair bit of cruft. All of our development projects to date have been based upon the .NET Framework v1.1. We're now about to start some projects using .NET 2.0, so it seemed like a good idea to create a new, fresh repository that would hold the new projects, and the converted versions of any old projects we want to move forward.

This idea is based on two premises: 1) that Vault performance will be better with a smaller repository, and 2) that once we convert an application from 1.1 to 2.0, we'll rarely need to go back to the old source code, and won't mind having to go into a separate repository for it.

Anyone with experience to confirm or reject the assumptions above?

Now, on to part two: If we are going to create a new repository, we have a fresh opportunity to do things right. So, what are the best practices for setting up a project tree? For example, it seems like a good idea to put the Solution files in a top level folder, above the individual projects. Any other recommendations?

[lbauer]

Yes, creating a new repository makes sense.
As a matter of fact, we have a KB article on this topic:

http://support.sourcegear.com/viewtopic.php?p=5183#5183

One suggestion on organizing code would be this:

trunk/
src/
doc/
tests/

Add your solutions/projects to "src." When you add solutions, use Visual Studio's File->Source Control-> Add Solution/Project to Source Control. Visual Studio has its own ideas on how things should be structured and we'd suggest following that for best integration.

http://support.sourcegear.com/viewtopic.php?t=776

Other users -- if you have suggestions, please chime in.