I’ve always wondered how an actively developed common library used in two or more projects should be stored in version control. I imagine it can be handled differently than a third-party library, since an in-house library is more likely to get hot fixes that should be distributed to many of the projects in version control.
Should its binary files be imported into the projects that use it as it is updated (pretty much like a third party library), or could its source code be checked out together with the projects? Is it possible to have references to other version controlled paths in Subversion or other version control systems?
I’m working in a project now that has common libraries that reside elsewhere in Subversion (and used in many projects) checked in with the project, so any changes made to them in this project are not reflected in their “real” repository. I’m going to suggest some changes to this, but I would like some thoughts on what the best practice for handling these common libraries is.
As others have already mentioned, SVN’s externals are a good way to do this. Through them you can reference other parts of your repository (or other repositories, too, FTM). A project can reference the head of some other (library) project or some branch or tag. The latter two make for stability, the former one for always being up-to-date with the library.
I’ve seen various schemes along these line using CVS (no externals here, so it was checked-in scripts that had to be executed) and SVN. In the company I’m working now we have different top-level folders for projects and shared libraries. The projects can refer the libraries. On the project’s trunk these external references usually are to the libraries’ heads, on tags and branches projects refer to libraries’ tags (or, sometimes, branches).