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