11:54 a.m.
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
1:26 p.m.
+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.
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
2:19 p.m.
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" ...
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
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
2:29 p.m.
----- 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
2:48 p.m.
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:
----- 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(a)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
4:12 p.m.
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...
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
3:16 p.m.
>> 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.
let me rephrase: the problem of build script/integration and the external repo being
"separated" exists for both git and svn repo.
The specific issue on how how hudson's handles I agree is git specific.
>
> 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.
Yes, except is not really the jbosstools git repo - it would be one or more
jbosstools-build git repos to encapsulate the integration.
My hope is that its possible to update submodules without checking out/init all the
submodules so it would be trivial to maintain vs checking everything out (again);
haven't tried it enough yet to know.
/max
7:11 a.m.
+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 :-)
Libor
On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
<max.andersen(a)redhat.com> wrote:
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
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
9:39 a.m.
+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 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
Libor
On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
<max.andersen(a)redhat.com> wrote:
> 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
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen
10:59 a.m.
That said the new TP and parent pom for 3.3.indigo branch is simplified
in that all the deps from upstream (eclipse.org, sonatype, google) are
now mirrored on dl.jboss.org in a single composite repo [1], and we'll
have a second composite for the components as they're built (as we do
for 3.2) [2].
This means you can - *in theory* - build the parent pom (and target
platform) [3] or grab it from Nexus [4] (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
JBT components.
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
this theory.
[1] http://download.jboss.org/jbosstools/updates/indigo/
[2]
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
[3] http://anonsvn.jboss.org/repos/jbosstools/branches/3.3.indigo/build/
[4] http://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/
N
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 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
>
> Libor
> On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
> <max.andersen(a)redhat.com> wrote:
>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)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
12:16 p.m.
This means you can - *in theory* - build the parent pom (and target
platform) [3] or grab it from Nexus [4] (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
JBT components.
where would the (aggregated?) upstream of jboss tools live ? (not together with the base
targetplatform I assume)
/max
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
this theory.
[1] http://download.jboss.org/jbosstools/updates/indigo/
[2]
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
[3] http://anonsvn.jboss.org/repos/jbosstools/branches/3.3.indigo/build/
[4] http://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/
N
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
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
>
>
>>
>> Libor
>> On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
>> <max.andersen(a)redhat.com> wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)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
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen
3:30 p.m.
On 03/07/2011 01:16 PM, Max Rydahl Andersen wrote:
> This means you can - *in theory* - build the parent pom (and
target
> platform) [3] or grab it from Nexus [4] (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
> JBT components.
where would the (aggregated?) upstream of jboss tools live ? (not together with the base
targetplatform I assume)
All of the URLs below are update sites.
Input to Target Platform (Indigo Composite Requirements Mirror) [1]:
[1] http://download.jboss.org/jbosstools/updates/indigo/
Indigo-Based Target Platform [5]:
[5]
http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/l...
JBoss Tools 3.3 Composite Staging Site [2]:
[2]
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
> 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
> this theory.
>
> [1] http://download.jboss.org/jbosstools/updates/indigo/
> [2]
> http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
> [3] http://anonsvn.jboss.org/repos/jbosstools/branches/3.3.indigo/build/
> [4] http://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/
>
> N
>
> 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 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
>>>
>>> Libor
>>> On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
>>> <max.andersen(a)redhat.com> wrote:
>>>
>>>> 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 ?
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Eclipse Modeling & Dash Athena
http://nick.divbyzero.com
5008
days inactive
5015
days old
jbosstools-dev@lists.jboss.org
11 comments
4 participants
participants (4)
-
Gary Brown -
Libor Zoubek -
Max Rydahl Andersen -
Nick Boldt