This means you can - *in theory* - build the parent pom (and target
platform)  or grab it from Nexus  (if we decide to keep deploying
stuff there?), check out a component's sources from github, and build
that component against upstream eclipse deps + upstream previously-built
where would the (aggregated?) upstream of jboss tools live ? (not together with the base
targetplatform I assume)
In other words... I think moving to github, one component at a time, MAY
BE VIABLE, but there's still a lot of testing left to do to validate
On 03/07/2011 10:39 AM, Max Rydahl Andersen wrote:
>> +1 for git.
>> Work with svn is very slow and disk-consuming and I have still issues 'svn
>> up', it still needs cleanup, or refuses to update. I started to hate svn,
>> please unschackle me :-)
> Btw. Nick and I had a chat the other day about what actually prevent us from moving
> if it was just a question about git vs svn then we could easily move (assuming
> 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
> thus not trivial to move away from git fully :(
> Will require a lot of effort.
>> On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
>> <max.andersen(a)redhat.com> wrote:
>>> 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 ?
>>> jbosstools-dev mailing list
>> jbosstools-dev mailing list
> jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Eclipse Modeling & Dash Athena
jbosstools-dev mailing list