When coding, I naturally often come up with classes or a set of classes with a high reusability. I’m looking for an easy, straight-forward way to work on them separately.
I’d like to be able to easily integrate them into any project; it also should be possible to switch to a different version with as few commands as possible.
Am I right with the assumption that git (or another VCS) is best suited for this? I thought of setting up local repositories for each class/project/library/plugin and then just cloning/pulling them. It would be great if I could reference those projects by name, not by the full path. Like git clone someproject.
edit: To clarify, I know what VCS are about and I do use them. I’m just looking for a comfortable way to store and edit some reusable pieces of code (including unit tests) separately and to be able to include them (without the unit tests) in other projects, without having to manually copy files. Apache Maven is a good example, but I’m looking for a language-independent solution, optimally command-line-based.
3
As @jgauffin points out package management really is the way to fly here. But not everything has a package manager. Or other times you just need the sources riding with things.
Specifics are really a function of what platform, thing you want to look at here would be the sorts of features exposed by git submodules or hg subrepos. Both are designed to pull some part of your source repository from an external source. In the case of hg subrepos they don’t even need to be HG — git or svn can be accessed as well.
The real challenge comes in when you want a subrepository but you need to edit some certain files within it.
I would keep them in a repos somewhere and then use a package tool to include them in my projects.
- .NET has
nuget. - Javascript has
npm - Ruby uses
gem
etc.
A VCS is the way to go. What you need here is to decide how you are going to store you code/configuration items in your VCS repository. The first question that I would ask is how stable are these reusable components?
If they are not going to change very much, then put then into a repository/database/project/folder/(what ever terminology your VCS uses) of their own and label them according to the product they correspond to. Then when it is time to do some coding, the developer gets the system they are working on from its repository and then the shared stuff, using the appropriate label to get the appropriate versions.
If the shared libraries will only change a little bit over time, then add some branching for the development lines that need it and use labels. Now you can get the required files/versions as per the above using the appropriate labels. You then need a management process to periodically update the trunk with these branches and test it with all the affected applications.
If there is going to be a lot of customization, then you probably need to maintain separate repositories per project as that will be easier/cheaper to manage that over a bunch of repositories with lots of branches/labels/promotion groups and the integration testing that that entails.
To extract them, use some tool if you can be bothered to work out how to configure it. Or, write a quick script to get the files needed per project and create the file structure for the project when you need to start off some development, Something like this psudo code:
required_label = "version 1.1.1"
project = "funStuff"
destination = "server/share/folder/"
get from vcs project $project $required_label into $destination
get from vcs "library project" $required_label into $destination/lib/
echo “get to work”
This may not work if you used a IDE inbuilt version management integration. The developers may need to use the VCS’s interface to check in/out configuration items that are going to be changed.
The key to making this work is to make sure that the appropriate labeling system is enforced by the VCS – the ones I have used allow you to set up a rule forcing the adding or a label on check-in or have the facility for floating labels. Use as appropriate.