2009/2/24 aslak hellesoy <aslak.helle...@gmail.com> > On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland <rob.holl...@gmail.com> > wrote: > > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne <m...@mattwynne.net> wrote: > > > >> You can even use git commit --amend to commit on red (e.g at the end of > the > >> day) and then change that commit later. > > > > While I think commit --amend is very useful, I'm not sure why you'd > > bother to commit at the end of the day, knowing full well you were > > going to amend it first thing tomorrow morning. > > > > Because the longer you wait, the more your code will diverge from your > teammates'. If you don't commit often you rob them of the opportunity > to reduce merge hell.
This is the money line for me. There's a lovely CI pattern I've seen in the centralised SCM world (with Java, but that's less important) that I'm surprised hasn't been mentioned. Before I describe it I'd like to take this back to first principles. The point of *continuous* integration is to keep each individual integration small and avoid less frequent *big* integrations, because that's where the pain happens. Syncing up once per story or feature, which could easily be several days work, strikes me as a retrograde step. The fact that DSCMs like git or hg allow you to do this doesn't make it a good thing. There are many fantastic reasons to use DSCM - modelling IBM Rational ClearCase "best practice" usage patterns shouldn't be one of them. Anyhoo, it seems to me the problem we are discussing is the coupling between checking in an unfinished scenario and failing the build. The solution I've seen - scaling to projects with tens of developers and thousands of scenarios - is to separate in-progress features from finished ones, and build everything. If an in-progress scenario fails then the build carries on. If a completed scenario fails it causes the build to fail. There is a nice corollary to this whereby you fail the build if an in-progress scenario accidentally * passes*. This is because you usually want a human to find out why. In cuke-land you would do this at a feature level rather than a scenario level since the convention is to have one feature (with multiple scenarios) per file. Marking a feature as done can be as simple as moving it between two directories (called in-progress and done), renaming the feature (from openid_login.in-progress to openid_login.feature) or having an :in_progresstag on a feature until it's done. In Java-land I prefer the first model because I can point the same junit task at either the in-progress or done directories and just change the failOnError flag. In any case, I would strongly encourage changing the build so you can integrate continuously - i.e. git push as frequently as you normally would - knowing the build will remain clean as long as you mark your unfinished work as in-progress. Lightweight, cheap branches are great for local spikes, exploration of unfamiliar code and any number of other incidental activities, but I'm deeply sceptical that they should form part of your core workflow. No doubt once this becomes the norm and Rational are laughing up their sleeves I'll live to regret saying that :) Aslak Cheers, Dan
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
