[dna-dev] Version control poll

Brian Carothers brian.carothers at amentra.com
Wed Dec 9 08:03:59 EST 2009


Comments inline.

> -----Original Message-----
> From: dna-dev-bounces at lists.jboss.org [mailto:dna-dev-
> bounces at 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? :-)



More information about the dna-dev mailing list