Library version control best practices

Question

I may be violating some StackOverflow terms by asking a question which is more likely to yield discussion than a clean answer. Here goes, however.

I've developed some software for a small company that isn't a software house (so we don't already have a lot of processes in place). It is in Turbo Pascal (Delphi 2009) and my source is version controlled (CVS).

I use several third party components (graphing, TCP comms, etc.) In Delphi, the default behavior is for the source for these to be stored in an include folder under the the Delphi IDE program files folder.

It's now time to pass this project off to another developer. Now he'll have to install the IDE + components in order for them to appear correctly when editing forms in this application. But I'd like our production build process to be automated and I'd like a build server to be able to perform a code checkout and compile.

This means I think I really need to put all the source code (or at least the DCUs where I don't have the source files) for these 3rd party addons in source control. I think they should be part of the CVS module for the software project being developed (i.e. not their own source controlled module).

I think we need to be able (as a small company) to point a future developer at the repository, and say "Check out this module" and he'll have everything he needs to be able to compile from the command line without doing anything else. (i.e. portability to new dev environments is important)

Is this sensible, or would it be more scalable for us to keep each library in its own version controlled state and then in the build script, pull the source code for this project, and the correct version of the source code for each library?

Thanks in advance, and my apologies for the rambling nature of the question.

Duncan

Answer 1

Well I don't think there is a single definitive answer. But I can tell you what happens at my place of work, and that is that the entire source code tree is under revision control: all my 3rd party components, all the odd C routines that get compiled and linked in, a number of .obj files etc.

It's really important for us to be able to have a repeatable build process and the above is really a pre-requisite for that.

Now, how to achieve that goal with your source control system is another matter altogether, but you should be aiming to be able to check out the entire project and be able to build it with no human intervention.

Answer 2

I will also chime in with how we do things at my company. We have one repository for the main project, and a separate repository for all of our Delphi components.

When I create a new release of the main project, I tag the release in both the project and component repositories.

I also have a build script which checks out either the trunk or a specified tag for both repositories, and then builds a release version of the project.

If the components you use in your project are only used in that one project, then I think it would make more sense to keep them with the project. On the other hand, if you use these third party components with other projects, then maybe it makes more sense to keep them in a separate repository.