Maven versioning in a git repository with Vincent Driessen's branching model
At the moment we are using cvs for version control. We would like to migrate to git using Vincent Driessen's branching model (http://nvie.com/posts/a-successful-git-branching-model/)
For building we are using maven.
We want to assign distinct maven versions (based on the git version) to the feature branches via pom.xml to keep our maven repository clean.
If you merge a feature branch into the development branch, the maven version would overwrite the destination branches maven version.
Is there any possibility to prevent this? Is our usecase moronic?
Custom merge drivers for standard merge cases would be very nice, but afaik they are only meant for exceptional situations?
Sounds like a sane idea. But why does the whole building have to take place on the same machine? You could set up separate machines (or even virtual machines) for building the branches you care about, so as to keep the different environments strictly separate (that is what I understand you are aiming at). The beauty of DVCS is precisely that they are distributed, you can ship off part of the project elsewhere.
Comming from CVS, getting used to git isn't going to be a smooth ride. Set up a small project which you care about (a toy project won't do) but which isn't critical (you will screw up, and need to perhaps start over to clean up) to get up to speed. Use git for your "personal" work (perhaps you have a set of small scripts automating repetitive tasks, configuration files, whatever).
Don't do this.
Git has no version numbers like CVS. Git uses hash codes. You can assign tags which kind of mimic the old CVS versions but that involves manual work.
Don't deploy feature branches to the main Maven repo. The main repo should only contain releases.
When you use feature branches, you can't deploy SNAPSHOT versions anymore since the SNAPSHOTs from different feature branches would overwrite each other.
Here is our solution:
Feature branches rarely leave developer machines. They are only pushed when several members work on the same feature.
Developers should run the build (incl. tests) on their local machine. A build server only builds the master branch and a select few feature branches.
When the build server builds a feature, it uses a distinct maven repo for this job. That means the build server has N local maven repos. You have to do this in order to keep the SNAPSHOT versions from overwriting themselves.
When a feature is finished, it's merged into the master branch. At this time, it becomes visible for everyone.
We never deploy SNAPSHOT versions to a shared Maven repo. The reason is simple: I deploy my SNAPSHOT version for feature X. Another developer comes in, starts his PC and builds a module. Maven will now happily download my SNAPSHOTs and break his build. Or not. The developer will have very odd errors. Executed code won't match the sources on his hard disk. Many hours will be lost.