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

[Max Rydahl Andersen]

> 
> 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/requirements
> 

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.

> 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).

that would remove the blame integration and we loose that important hudson feature to focus the build failure to those actually involved.

> 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.

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.

> Problem with (a) is I've never done it, and have no idea if it's possible.
> 
git submodules is what I *think* could work here - i'm not at all sure though.

> 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.

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 ? :)

> 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.
> 

git-svn is useless for me if it just gives me local commits; and its just as freaking slow as svn is.
> 
> What's the core reason for wanting to switch to Git in the first place? Better merge?

Yes! and that we need to break up in smaller bits to survive anyway; doing that with N svn modules makes my head spin.

> Better UI tooling?

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.

> Better support for distributed/offline development?

Yes!

> 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.

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