CODEWITHSUNDEEP
version-control
Adam Davis
Adam Davis

Reputation: 93625

How to manage shared libraries?

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:

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

-Adam

Upvotes: 9

Views: 2612

Answers (4)

ephemient
ephemient

Reputation: 204984

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.

Upvotes: 11

Lev
Lev

Reputation: 6667

Use version control, of course, as PersistenceOfVision said, and also keep a nightly build to make sure you don't break old projects.

Upvotes: 1

PersistenceOfVision
PersistenceOfVision

Reputation: 1295

Take your pick of Software Version Control packages...

For Example:
SVN + TortoiseSVN is our current solution. (Free)
Some prefer Visual Source Safe. (Not Free)

Upvotes: -1

Simon Howard
Simon Howard

Reputation: 9079

If the code is generic enough that you're using it in multiple projects, is it possible that you're reinventing the wheel? If, instead, you standardise on existing libraries, you'll have code that has already been well-tested and optimised, and you won't have anything to maintain.

Upvotes: 0

Related Questions