[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