Newbie question

Hans Meine meine at informatik.uni-hamburg.de
Mon Feb 2 03:43:03 CST 2009


On Sonntag 01 Februar 2009, Derek Scherger wrote:
> On Thu, Jan 29, 2009 at 8:47 AM, Douglas Philips <dgou at mac.com> wrote:
> > That is a policy decision. And if bisect enforces a policy decision it
> > is broken. period.
>
> I had this problem the other day, not with mercurial bisect mind you, but I
> don't think it matters. If the you can't build any particular revision you
> can't determine whether or not that revision introduced a bug or if it
> contained a bug or not. So, with a frequently failing build, bisect just
> doesn't work very well.

Still, that's a weakness of bisect, not of the policy.  It can imagine very 
well a way to mark changesets as "intended to be stable" (or vice versa, 
as "intermediate, non-working state"), and let bisect work only on stable 
revisions.  (I am also in favor of frequent checkins also of non-working 
revisions, i.e. from automatic merging or search&replace which only did 90% 
of the work but still need fixing.  This allows me to separate the 
interesting 10% of the changes - which probably took 90% of the time - from 
the otherwise dominating automatic onces.)

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090202/23be4470/attachment.pgp 


More information about the Mercurial mailing list