Re: [dna-dev] dna-dev Digest, Vol 21, Issue 10

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&gt; 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&gt; Subject: Re: [dna-dev] Version control poll To: JBoss DNA <dna-dev(a)lists.jboss.org&gt; Message-ID: <3E8F2B0F635FDE4CBEC121E3F3A2373A010F0CD3DB(a)AUSP01VMBX09.collaborationhost.net&gt; 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&gt; Subject: Re: [dna-dev] Version control poll To: Brian Carothers <brian.carothers(a)amentra.com&gt;, JBoss DNA <dna-dev(a)lists.jboss.org&gt; Message-ID: <95DDA177-1A76-4941-82B6-9D2BDE38B6F7(a)redhat.com&gt; 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 ***************************************