Great writing. Thanks On Wed, Mar 4, 2009 at 5:25 AM, Dan North <tasta...@gmail.com> wrote:
> 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_progress tag 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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
