2009/4/24 Brian Fox <bri...@infinity.nu> > > > Mark Struberg wrote: > >> technically there is no git repo which is 'better' than the other. This >> hierarchy is an orga one. >> If you can pull from my repo and from Jasons, from whom will you pull your >> master mainly? Bet you will pull from Jasons. And I also bet all >> contributors will try to get their changes being pulled by Jason and >> published in his repo at the end of the day. >> >> >> > I think the canonical one would be equivalent to the current svn, where > committers have access to push in changes. This would be required to > maintain the "code provenance" but it would still make everyone's life > easier to make changes and contribute them...and our lives easier to apply > them. > >> >> > Does Maven SCM support *fully* GIT? >>> >>> >> mvn release:prepare and release:perform is working with git since more >> than a year now. >> >> > I think this is slightly misleading.... > >> The only uncertain point is how we should handle multi-module builds. >> > Here's the rub. I talked with John after his chat with you on IRC. It seems > to be that the git scm actually clones the repo from the tag to > /target/checkout. (this is done because an actual checkout would replace the > current working folder out from under the running maven...not good either). > The problem is that a git tag is a tag of the whole repo, so the > target/checkout contains everything, not just the submodule being released. > Maven would need to know this and step into the correct folder before > executing the perform build.
FYI, this is a similar issue with the Accurev SCM... only with Accurev you cannot check-out into a sub-folder of a local workspace. It would be great if there was some solution to this. (Of course my work-around was to migrate everything from Accurev to Subversion, which took some work, but at least it's done now (except for one refusenick project)) ;-) -Stephen > > > Naturally this is a break from previous checkout based scm systems. The > proper fix (purely on speculation...i haven't looked at the code in a long > time) seems to be to allow the scm provider to calculate the correct path > for execution given a working copy. In svn's case, it would simply return > target/checkout, in git's case it would be either target/checkout or > target/checkout/xxxxx based on how the repo was constructed. > > This change would likely require an update to the interface, the release > plugin and the current scm wagons. Any takers? I'll probably dabble in it > myself if I can find some time. >
