Git based maven2 builds can't properly release or checkout on branch

The attached patch illustrates a crude workaround for the issues prevent checkout and release from a branch.

Once the maven-scm git provider is updated, as long as the pom includes the proper 'tag' attribute in the scm metadata, continuum (actually maven-scm) can properly checkout the project and switch to the branch named in the 'tag' attribue.

the patch doesn't apply cleanly to trunk, mostly because it's already been updated to a newer maven-release version. I'm not sure I understand your second comment - are you saying that this is already right in maven-scm trunk?

here's a naive application of the patch to trunk. I haven't checked it works yet - it seemed odd to be changing the method signatures when trunk had approached it differently (I think by delegating some of the methods). It needs a closer look, but I ran out of time.

It's better to address patches to trunk - the 1.3.x releases should be small, and we're overdue to get a 1.4.1 out anyway...

Brett, my apologies. A portion of the issue was solved by updating the maven-scm providers to 1.4 (so it should be right in trunk too). However, updating the working copy during release still didn't work right. During the working copy update phase the maven-scm update() call isn't passed the proper ScmVersion for the current working copy. It always is called with null. The git scm provider assumes that means you want to pull changes from master rather than the working copy's active branch (which seems rather odd to me, but I stepped around it). It essentially does a merge of two (possibly unrelated) branches.

I should have made it more clear that the patch was only meant to illustrate the issue and is a crude workaround and not a complete fix. I fully expected that someone with more understanding of this process could improve it greatly. I based it on 1.3.6 because it is the non-beta release and it can get users around the problem. Next time, I'll submit a patch for trunk and the current non-beta release. Would that work?

yep, I understand. I actually think the technique is quite acceptable (we have special cases for other SCMs around too), perhaps best if a concurrent patch is submitted to SCM so that it can be cleaned up as soon as the next release of that happens.

As for patching trunk & branch - that's certainly helpful in getting it applied to both, with the priority being for trunk since it always has to land there anyway. In this case, because of the scope of the change (upgrading libraries / crude fix), I think it's better not to apply it to 1.3.x and instead focus on pushing for a non-beta 1.4 release soon

Attached slightly modified patch that works on trunk.

did you intend to apply this to trunk now?

I didn't only because there are still limitations with the git-scm that make this a little weird. For instance, the tag element in the scm configuration in the pom isn't updated it doesn't track things properly, but it does solve the release/checkout issue.

It might be good to integrate it as it grants git users the ability to use continuum in a normal work flow. I can integrate into trunk as long as no one opposes. Barring that, backlog is ok.

no objections here

Committed in r1091054