On 4 Mar 2009, at 11:25, Dan North 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.
Thanks for your thoughts, Dan. Cucumber 0.2 tags are ideal for this
sort of filtering. I'm going to look at adding a 'two tier' feature
run to our build.
Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
