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

[Nick Boldt]

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

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:
>
>
> ----- Original Message -----
>> On Feb 28, 2011, at 20:26, Gary Brown wrote:
>>
>>> +1 for switching to git.
>>>
>>> Although there may be one slight build issue for Nick when dealing
>>> with the external modules (e.g. pi4soa, savara, etc). Currently the
>>> svn based hudson jobs check out a jbosstools build structure and
>>> then the project module to be built - in separate sub-folders. The
>>> build structure contains some publish scripts.
>>>
>>> Although the git part of the hudson job configuration allows
>>> multiple repositories to be specified, it only defines a 'Local
>>> subdirectory for repo (optional)' attribute for the git section as a
>>> whole, not per repository.
>>>
>>> So currently it attempts to fetch all of the git repositories into
>>> the same location in the workspace - which does not seem to work.
>>
>> Well this problem already exist today with "pure svn" ...
>
> Not sure it does, as the job Nick setup checks out different svn repositories into different locations in the workspace.
>
>>
>> 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 ?
>
> So if I understand correctly, the jbosstools git repo would aggregate the other git repositories (such as savara, jBPM, etc)? If so, then that sounds fine, as you say it can choose when to update the aggregated view of each module.
>
>>
>> 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
>>
>>
>>>
>>> Regards
>>> Gary
>>>
>>> ----- Original Message -----
>>>> Hey,
>>>>
>>>> We got our svn mirror now but after working with it a bit its
>>>> basically just as slow as normal svn (if you can get it to work).
>>>>
>>>> ...thus i'm wondering if anyone can come up with good reasons to
>>>> *not*
>>>> just move all new development over to git and simply kill off
>>>> the SVN completely for our jbosstools trunk development ?
>>>>
>>>> 3.2.x would stay in SVN.
>>>>
>>>> Comments/Suggestions/Screams/Objections ?
>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>
>> /max
>> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Eclipse Modeling & Dash Athena
http://nick.divbyzero.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-1.png
Type: image/png
Size: 43113 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20110228/2b156c5b/attachment-0001.png