Re: [jbosstools-dev] Git - do it fully or not ?

If you can have one Hudson job tied to one git repo which itself aggregates other git repos, then we're cool. (Currently, some jobs require as many as 3 or 4 SVN repo paths to be checked out in order to run). With Hudson + Git, you only get ONE git repo per job (see attached screenshot), which IMHO is a blocker unless: a) we can aggregate into a single repo something like "component sources" [1] + "JBT parent pom + target platform definition" [2] + "JBT test-time server runtime requirements" [3]. [1] http://anonsvn.jboss.org/repos/tdesigner/branches/7.1 [2] http://anonsvn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/build [3] http://anonsvn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/requi... or b) we can fetch sources a different way than the built-in Hudson mechanism (eg., shell script run in Hudson before a build to call `svn co` or `git clone` to get [2] and [3], with [1] being fetched/watched via built-in SCM support). Problem w/ (b) is that we need at least the "component sources" to be fetched via Hudson in order to use its built-in build trigger for SCM change; but we probably don't care if "parent pom / TP" or "requirements" have changed, so not being able to build based on those changing is less of a problem. Problem with (a) is I've never done it, and have no idea if it's possible. Alternatively (c), if everything's in one massive repo, then the above issue is not a problem because we can just clone the whole repo (eating a ton of unnecessary b/w and disk space, and making builds take longer / possibly fail more often). Where plan (c) falls apart is where the component sources aren't in the same place as the rest of of JBT (teiid, drools, savara, pi4soa), so this would force those components to move into the JBT git repo. ---- Ultimately, I think the optimal solution here is either to stay w/ SVN as we do currently and use git-svn as the front end (which IMHO is faster / more stable than using pure svn)... or develop some hybrid solution involving aggregated git repos (?) if that's possible. One massive repo is doable too but will slow us down and waste time w/ slaves running out of space, bandwidth issues, time delays, etc. ---- What's the core reason for wanting to switch to Git in the first place? Better merge? Better UI tooling? Better support for distributed/offline development? I'm asking because if it's just "Git is shinier than SVN" but migration brings with it a whole host of new not-so-shiny issues, one might argue we're better off with the status quo (or git-svn) than with a switch. Nick On 02/28/2011 03:29 PM, Gary Brown wrote: -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio Release Engineer :: Eclipse Modeling & Dash Athena http://nick.divbyzero.com