I develop a variety of applications and have 3-4 miscellaneous libraries that I reuse across these apps (one for math, one for database functions etc.).
Currently I have one master source directory with each project as a top level directory (including my helper projects). And each project that needs a helper adds the entire project as a reference in the solution (not against the library). This allows for quick debug/updates of the helper library, but gets cumbersome quickly as I always have to rebuild the helpers and can make breaking changes to interfaces used by much older programs.
All of these are stored in a trunk directory of a subversion repository, and when I branch particular directories I create a massive branch, etc. This is quite difficult to maintain backwards compatibility as well as just shear code size and local size of the repository.
What is the best way to handle these situations? How do you layout your various projects.
Do you put each project in its own subversion repository? Or do you use one repository with multiple top level projects and trunk/branch/tags beneath that?
How do you reference alternate projects? Do you just compile these and reference the data?
Please see my answers at Projects folder structure recommendation and How do you organize your version control repository?.
For your specific question, the issue is managing inter-project dependencies. The answer is to version them–each project that depends on another should depend ONLY on the binary deliverable from that project (or the closest equivalent if not a compiled program/library), and that deliverable should be versioned in each such reference. Of course, you first need to make sure that each project produces ONE and ONLY ONE binary deliverable (or equivalent).
By depending only on the binary deliverable from another project, you make each project stand-alone and greatly ease its maintenance, since its ‘build interface’ is a single file. Reaching into another project’s source/build is like reaching into the middle of a library’s implementation = lots of problems.
By versioning each project, you can modify a particular project’s source on behalf of another (new) project, but not affect any of the other old projects that used it. In effect, each project becomes a PRODUCT. Like any product, you should manage its releases and its compatibility with other products.