Re: [Monotone-devel] new bisect command

[Thomas Keller]

Am 19.11.09 06:48, schrieb Derek Scherger:
> I've finally found the time to finish up the bisect command I started
> working on earlier in the year and it's now ready for review on the
> net.venge.monotone.bisect branch.

Looks good to me, a few observations:

1) If an update to a revision failed, f.e. because the addition /
removal of a node is blocked because of unversioned files, it tells me
to re-run the process with --move-conflicting-paths - however what
should be re-run here is only the update, because the bisect status has
already been updated.

2) When two revisions are bisected which have no revisions in common
(f.e. because they don't have the same root revision), bisecting them
just gives me the starting revision. Maybe this is not a common case,
but maybe we could be smart enough to detect if a given revision is not
even part of the same tree?

3) A localized date output format for the revision and maybe a hint on
which branch it is would be nice.

4) If I'm in the mid of a bisecting operation and (accidentially) call
mtn up, I'm updated back to the head revision (if that is possible at
all) of the branch I'm bisecting. I can easily go back to the last
revision to test by simply reissuing mtn good or mtn bad on an already
marked revision (I tested that - cool!), but somehow I wished mtn bisect
status would just tell me the revision which is currently tested so I
could also update my workspace revision by hand... (this would also be
handy for problem 1) when the update to a certain revision fails for
some reason)

> There's one item I'd like some feedback on before merging this to
> mainline though: In the process of bisecting, the various bisect
> good/bad/skip commands update the workspace to the next revision to be
> tested based on the results of the last test. In doing so, these
> commands do *not* update the workspace branch option in _MTN/options,
> partly because there's no guarantee that the selected revision has a
> branch option, or that it has only one branch option and I don't think
> it's sensible for bisect to fail in these cases. If, in the middle of a
> bisection operation, one finds the bug they're looking for, and commits
> a fix against that rev before completing the bisection, there's the
> possibility of using the current workspace branch option when they might
> have intended to commit to some other branch. I'm not sure what the best
> way to deal with this is. One option would be to make lots of other
> commands fail if there is a bisection operation in progress, but that
> doesn't seem particularly great. I'm interested if anyone else has ideas
> on how to handle this, or whether it's actually a real problem that even
> needs to be handled.

The simplest approach I could think of is to at least note in the output
of mtn status that the parent revision is not in the same branch as what
is noted in _MTN/options for the workspace. This might also be handy for
people screwing around with _MTN/options to branch-off some trunk for a
feature branch (the "long awaited" (tm) mtn branch command should fix
that :) and I think its reasonable to give this information there
because in my opinion mtn status is the most-used command _before_ a
commit happens.

Good work!

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature