I have been starting to play with git for the jetty @ eclipse source base, still backed by svn but just to get a feel for how it works...and its pretty neat.
that said, I would say that maven3 is the prime mvn target to iron out the mvn issues with release plugins and all the other core toolchain bits.. once that stuff is working then that should be the proof positive required to get the rest of mvn moving in that direction, or enough experience that it isn't right for the other parts of maven... look how long it took eclipse to get core svn support, subversive is due into the core of it the next release I think...so years and years... but there is already an eclipse GIT project underway in incubation (or at least starting incubation soon, whichever the case may be) I am rather hoping the eclipse foundation supports git projects and if the governance issues that jason refers to can be ironed out then that is a big ole plus for eclipse ip processes, that would be really nice...and apache is getting there as well jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Apr 24, 2009 at 09:29, Christian Edward Gruber <christianedwardgru...@gmail.com> wrote: > > On 24-Apr-09, at 10:20 , Paul Gier wrote: > >> Mark Struberg wrote: >> Is sounds like the process used by our release plugin doesn't really match >> the way git works, so maybe we can change the way the release plugin works >> instead of trying to fit git into our model. Do we really need to do a >> clean checkout from the tag? Git must have a way to just check that the >> local working copy is exactly the same as the tag on the server, right? As >> long as we have a good way to verify that what we have locally matches >> what's on the server, I don't think it's absolutely necessary to do a clean >> checkout. > > I don't disagree in theory, so long as your stated criteria could be > achieved. I'm just not sure that the criteria can be provably met, because > there may potentially be artifacts locally that aren't tracked by the SCM > which could corrupt the environment of the build, or even source > (unchecked-in files, etc.). I don't know how GIT manages the local > workspace, so I can't tell if it's a problem. SCM has metadata locally, so > it handles this and you can use "svn st" to discover this. Perforce, on the > other hand, doesn't have such metadata, so it's more difficult. I think as > a policy it's dramatically safer to have a clean checkout or export of the > canonical version from the repo to be used for the release. > > cheers, > Christian. > > Christian Edward Gruber > e-mail: christianedwardgru...@gmail.com > weblog: http://www.geekinasuit.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
