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  and , with  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
git submodules is what I *think* could work here - i'm not at all sure
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?
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
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.