On Feb 28, 2011, at 20:26, Gary Brown wrote: Well this problem already exist today with "pure svn" ... But I was actually thinking that the hudson integration jobs would be done by a git repo that has the its 1 or more related repos as a git submodule. That would make it work I think plus we get stability (i.e. it doesn't move automatically on every change unless we want to) plus we get a versioned repo of the actual build setup. WDYT ? note - for jbosstools what I see happening is that we start by simply using a copy of svn repo into one big git repo and then over time move each "module" out into its own git repo (the challenge is to define what module or set of modules goes into a repo) /max /max http://about.me/maxandersen

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

i think these are done wrong in the first place....i.e. requirements, parent pom and target platform definitions should be versioned and released like anything else. That said, git submodules could/should help. that would remove the blame integration and we loose that important hudson feature to focus the build failure to those actually involved. Of course we care if parent pom or requrirements have changed...but that comes back to it being done weird today; this is separate from any git/svn discussion IMO. git submodules is what I *think* could work here - i'm not at all sure though. yes, and that simply won't work. We've tried to do that for years now and people still go and create their own thing and stay there....if they won't come to the mountain the mountain have to come them...isn't that how it goes ? :) git-svn is useless for me if it just gives me local commits; and its just as freaking slow as svn is. Yes! and that we need to break up in smaller bits to survive anyway; doing that with N svn modules makes my head spin. I haven't seen better git tooling; egit looks like svn git integration..... more important for me is that its supertrivial to setup git repos and share them; something I think will be very useful for collaboration both externally and internally. especially for those parts that can't be part of JBoss Tools yet. Yes! Right now I find very few actually to take full ownership of their module - we need to make that happen; reasons for it not happening have been many; some say "I don't care", other says "I don't look at others code because it takes too long to checkout", "I can't reproduce what hudson does", etc. I believe a major factor to change this is I believe is by separating into modules - and again, doing that in svn is *dog slow*; with git its criminally fast in comparison. Just look at any other project of our size....I don't see *any* be this monolithic ....for sure that monolith is serving its purpose for sure but it is also hiding a lot of issues and it is preventing scaling. My biggest fear for sure is that not everyone groks git yet - I for sure does not yet; but that is why I suggest we move the full svn repo over to one big git repo and learn from there. Alternatively is to split up our svn into modules instead first...but that's alot of overhead for something we can move to easier. Note, i'm for sure not sure about this move to git which is why I'm asking.....but now is the time to do it if ever. /max

Btw. Nick and I had a chat the other day about what actually prevent us from moving and if it was just a question about git vs svn then we could easily move (assuming windows users are fine with using bash/cygwin) The challenge is that hudson+git is not as flexible as it currently is with svn and we don't yet have a good use of having our builds pick up latest/matching dependencies from a repository - thus not trivial to move away from git fully :( Will require a lot of effort. /max /max http://about.me/maxandersen

where would the (aggregated?) upstream of jboss tools live ? (not together with the base targetplatform I assume) /max /max http://about.me/maxandersen