Question

Every time I make a project I develop several generic routines/modules/libraries that I expect I’ll be using with other projects.

Due to the speed of development I don’t spend a lot of time making these modules perfect – just good enough for this project, and well enough documented and isolatable that I can easily add them to another project.

So far so good.

Now when I use them in another project inevitably I improve them – either adding new features/functions, fixing bugs, making them more general, etc.

At that point I have several problems:

• I need to maintain the changes in the module for the code I’m working on
• I need to maintain those same changes in a central ‘module’ repository
• I need to make sure that the updated modules are available for, but not automatically used in older projects, or sometimes even existing projects I’m already working on.

How do you manage this? How are these problems different when you have teams working on various modules in different projects?

-Adam

Answer 1

If you’re using Subversion for all your projects, you can simply use svn:externals: this allows one repository to reference another repository, optionally fixed at a particular revision. For example,

svn://svn/shared svn://svn/project1   |- dir1   |- dir2   \- svn:externals 'shared -r 3 svn://svn/shared' svn://svn/project2   |- dir3   \- svn:externals 'shared -r 5 svn://svn/shared'

Commit your changes to svn://svn/shared, and modify the svn:externals property in the individual projects when you’re ready.

Otherwise, using other VCS, you might simply keep a bunch of tags on shared, one for each project using shared, pointing to the version they use. Advance each tag to later versions when ready. This requires manually updating each project’s copy of shared, though (one thing which makes svn:externals nice is that it happens automatically).

If you’re forking/branching shared for each individual project… well, that can work, but it takes manpower to maintain and merge changes.

[Edit]

Further references:

See External Definitions in the svn book for a tutorial and more details on svn:externals, and git-submodule tutorial for a similar feature in the DVCS git.