Re: [dna-dev] Version control poll
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? :-)