Hello together,
may be a change to Git is a great idea, but we need to know how quickly a developer can
work with Git and eclipse. Because I know that for SVN there are a lot SVN plugins, that
can be use with eclipse.
Or may be we can wait for a stable great eclipse Git plugin.
Cheers,
Serge.
-------
|||| Serge Emmanuel Pagop
|||| IT Senior Consultant
||||
||||
|||| innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
||||
|||| Business mobile: +49 178 4049592,
|||| Business Fax: +49 2102 77160-1,
|||| Business E-Mail: serge.pagop(a)innoq.com,
|||| Private E-Mail: serge.pagop(a)googlemail.com
|||| Web:
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. DNA nightly integration on JDK1.5 - Build # 609 - Still
Unstable! (jboss-qa-internal(a)redhat.com)
2. Re: Version control poll (Brian Carothers)
3. Re: Version control poll (Randall Hauch)
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 Dec 2009 02:16:13 -0500 (EST)
From: jboss-qa-internal(a)redhat.com
Subject: [dna-dev] DNA nightly integration on JDK1.5 - Build # 609 -
Still Unstable!
To: dna-dev(a)lists.jboss.org, rhauch(a)gmail.com
Message-ID:
<693109249.4141260342973772.JavaMail.hudson(a)soa8.qa.atl2.redhat.com>
Content-Type: text/plain; charset=us-ascii
DNA nightly integration on JDK1.5 - Build # 609 - Still Unstable:
Check console output at
http://hudson.qa.jboss.com/hudson/job/DNA%20nightly%20integration%20on%20... to
view the results.
------------------------------
Message: 2
Date: Wed, 9 Dec 2009 07:03:59 -0600
From: Brian Carothers <brian.carothers(a)amentra.com>
Subject: Re: [dna-dev] Version control poll
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID:
<3E8F2B0F635FDE4CBEC121E3F3A2373A010F0CD3DB(a)AUSP01VMBX09.collaborationhost.net>
Content-Type: text/plain; charset="us-ascii"
Comments inline.
> -----Original Message-----
> From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
> bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
> Sent: Tuesday, December 08, 2009 2:47 PM
> To: JBoss DNA
> Subject: [dna-dev] Version control poll
>
> Personally, I've been using Git locally for many months, and couldn't
> imagine going back. I simply love the ability to have local branches
> (that are almost always named for the JIRA issue) and to switch between
> them very easily. And I'm not even benefiting from the ability to push
> these branches out anywhere else. The Git Eclipse plugin works very well
> for me, but I'm very used to the command-line and don't expect much from
> my Eclipse Team UI functionality anymore. (I really just want Eclipse to
> tell me which files are changed locally, which the plugin does very well -
> everything else I use the command line for because its far easier IMO.)
There were several times this year when I was working on multiple issues simultaneously
(or had completed 1-2 issues pending review and had started on another). I ended up
having to create patches and revert as I shifted between issues or only work on issues
that affected completely different sets of files (e.g., one connector-layer issue and one
JCR-layer issue) and remember which was which.
I broke the build many times because I fouled up this process.
In theory, Git would make this much easier, right?
> However, I do have several concerns. One of them is whether this raises
> or lowers the bar for people downloading the source, submitting patches,
> or for becoming new committers.
I think it will. Had this project been git-only a year ago, I probably never would have
gotten involved. It's not that git is bad or that learning git is hard, it's just
one more bit of inertia to overcome.
> For people that only have SVN experience,
> I think this will dramatically raise the bar because Git will be a big
> unknown for them. On the other hand, Git is becoming extremely popular
> and used on a lot of projects, so while this might be the norm now, I
> don't expect it will be in a year.
Then, IMHO, we should move to Git in a year and let other projects train people, develop
best practices, and support tooling improvements. IMHO, I think we should be focused on
advancing the state-of-the-art in federating data sources, not in build processes.
> For people that do know Git, our using
> Git would actually _lower_ the bar for their submitting patches, because
> they can create a patch on their own Git repository (or if that's not
> accessible then on a site like GitHub) and give us a URL, where we can
> pull it in to review and possibly commit.
I think that the set of people who know Git, know Java, and might submit a DNA patch is a
very small one right now. I think the set of people who might build from trunk right now
(a prereq for creating a patch) but wouldn't bother if it meant they had to install
and learn Git is a larger set.
But that's right now. I wouldn't be shocked if things were different by this
time next year.
> Another concern is what the Git experience is on Windows, which I can't
> evaluate. The Git experience is pretty much the same on OS X, Unix, and
> Linux mostly because command-line support is so similar. But while
> Windows has very different command-line support, it does seem that msysgit
> (
http://code.google.com/p/msysgit/) gets around that issue pretty well.
> I'd love to hear about your experience with Git on Windows, though.
I'll try this out post-0.7 and let you know.
> One concern I have had in the past was whether our Hudson continuous
> integration system will support Git. I happy to say that a Git plugin for
> Hudson has been available for some time, that our Hudson team have a test
> environment where they've install it, and I will be creating some test
> jobs for them. So while this still is an issue, it shouldn't be within a
> few weeks of the New Year (or sooner if I can find the time).
Why would we want to be the guinea pig for this? :-)
------------------------------
Message: 3
Date: Wed, 9 Dec 2009 09:04:45 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: Re: [dna-dev] Version control poll
To: Brian Carothers <brian.carothers(a)amentra.com>, JBoss DNA
<dna-dev(a)lists.jboss.org>
Message-ID: <95DDA177-1A76-4941-82B6-9D2BDE38B6F7(a)redhat.com>
Content-Type: text/plain; charset=us-ascii
On Dec 9, 2009, at 7:03 AM, Brian Carothers wrote:
> Comments inline.
>
>> -----Original Message-----
>> From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
>> Sent: Tuesday, December 08, 2009 2:47 PM
>> To: JBoss DNA
>> Subject: [dna-dev] Version control poll
>>
>> Personally, I've been using Git locally for many months, and couldn't
>> imagine going back. I simply love the ability to have local branches
>> (that are almost always named for the JIRA issue) and to switch between
>> them very easily. And I'm not even benefiting from the ability to push
>> these branches out anywhere else. The Git Eclipse plugin works very well
>> for me, but I'm very used to the command-line and don't expect much from
>> my Eclipse Team UI functionality anymore. (I really just want Eclipse to
>> tell me which files are changed locally, which the plugin does very well -
>> everything else I use the command line for because its far easier IMO.)
>
> There were several times this year when I was working on multiple issues
simultaneously (or had completed 1-2 issues pending review and had started on another). I
ended up having to create patches and revert as I shifted between issues or only work on
issues that affected completely different sets of files (e.g., one connector-layer issue
and one JCR-layer issue) and remember which was which.
>
> I broke the build many times because I fouled up this process.
>
> In theory, Git would make this much easier, right?
Every day (literally!) I switch branches to work on something else, without ever creating
a patch. (Git has the uber-handy 'stash', but that's only needed if
you're not ready to commit your changes locally.) Sometimes I do this multiple times.
Oh, and I get version control on all my branches, and Git does help merge changes between
different branches. So for example, if you fix an error on one branch (that hasn't
yet been pushed to trunk), you can pull that change (or all the changes on that branch)
into your branch with a simple merge.
Git-SVN provides this functionality locally. But that's a still nowhere near what
using Git all 'round will give you. Right now, if I needed a fix that you have
locally, I would need to get a patch (even if we were both using Git-SVN locally). If we
were using Git all 'round, we'd still push commits on our branches to a shared Git
(and merge them onto the 'trunk' branch (we'd probably use a branch name that
corresponded to the release effort), but I could very easily pull in some or all of your
changes in my branch. Easy-peasy.
>
>> However, I do have several concerns. One of them is whether this raises
>> or lowers the bar for people downloading the source, submitting patches,
>> or for becoming new committers.
>
> I think it will. Had this project been git-only a year ago, I probably never would
have gotten involved. It's not that git is bad or that learning git is hard, it's
just one more bit of inertia to overcome.
I'd probably agree with you. A year ago, Git didn't have nearly the uptake that
it does have now. Today, I think the "standard" for new projects is either Git
or Mercurial.
>
>> For people that only have SVN experience,
>> I think this will dramatically raise the bar because Git will be a big
>> unknown for them. On the other hand, Git is becoming extremely popular
>> and used on a lot of projects, so while this might be the norm now, I
>> don't expect it will be in a year.
>
> Then, IMHO, we should move to Git in a year and let other projects train people,
develop best practices, and support tooling improvements. IMHO, I think we should be
focused on advancing the state-of-the-art in federating data sources, not in build
processes.
I don't want to switch to Git because it's cool or fun or state of the art. I
want to switch because Git-SVN already makes my life an order of magnitude easier (lots of
branch switching), and would be another order of magnitude if we went whole-hog Git. Yes,
all the committer's processes would change, because we'd be moving to doing all
work on branches, and the main release branch becomes nothing but a merge point.
...
>> One concern I have had in the past was whether our Hudson continuous
>> integration system will support Git. I happy to say that a Git plugin for
>> Hudson has been available for some time, that our Hudson team have a test
>> environment where they've install it, and I will be creating some test
>> jobs for them. So while this still is an issue, it shouldn't be within a
>> few weeks of the New Year (or sooner if I can find the time).
>
> Why would we want to be the guinea pig for this? :-)
Because it's not much work (provide a Git repository, define a Hudson job that works
like ours, and help them work out the kinks), and I'm oh-so-tired of SVN. :-)
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 21, Issue 10
***************************************