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
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With