Re: [Monotone-devel] new bisect command

[Thomas Keller]

Am 24.11.2009 06:57, schrieb Derek Scherger:
> On Fri, Nov 20, 2009 at 4:01 PM, Thomas Keller <address@hidden> wrote:
> 
>> 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.
>>
> 
> Maybe the update of the status information should be delayed until after it
> has succeeded? I'll think about this one a bit.

If so, then the bisect commands would also have to carry the
--move-conflicting-paths options and logic.

> 3) A localized date output format for the revision and maybe a hint on
>> which branch it is would be nice.
>>
> 
> I'm using describe_revision throughout and I notice that it doesn't
> currently handle localized date formatting. Maybe we should change this on
> mainline and I'll just get that for free? I also wonder whether describe
> revision should be a hook so people can customize it to their liking. I've
> often thought that date should be listed before author, because dates are
> fixed length strings and authors are not and this might make for slightly
> better output. I wonder if anyone is strongly attached to the current
> output?

I haven't looked at the implementation, but if you say this is a common
code path, then yes, we should change it in mainline.

I'm not particularily fond to make every single piece of output monotone
gives configurable via a hook. If there's consent to reorder the output
of describe_revision, then we should probably just do so. Otherwise we
end up with a big chunk of hooks which change the output somehow which
nobody quite follows and which may just slow down the output (I don't
know how much of a time penalty there is to call into lua, but there
certainly is one).

>  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)
>>
> 
> It would be easy to list the last tested revision with its good/bad status.
> Perhaps I should have it list all explicitly tested revisions, in order?
> I did wonder a bit about whether a bunch of workspace modifying commands
> should refuse to operate while a bisection is in progress but I'm not sure
> if this is a good idea.

No, I don't think this is a good idea. Bisecting after all doesn't screw
at all with the workspace (ie. it continues to be fully workable).

> 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.
>>
> 
> I' hoping to get back to the changelog-editor branch that I started a while
> ago and the idea of marking the 'Branch: ...' line with a "(new)" or
> "(changed)" flag might be appropriate in this case. I still like the general
> idea on this branch that the display of a revision from status (an
> uncommitted revision), commit (a revision being committed) and log (a
> previously committed revision) should be reasonably consistent. Including a
> bit more information in the status case (whether the branch has changed,
> maybe where the root of the workspace is, etc.) seems fine too.

Yes, sure, thats definitely something which would be cool. However, to
get bisecting complete, I'd still say it would be enough in first
instance to just give mtn status a hint about an ongoing bisection. We
can still rework this later on the changelog editor branch.

> I also recall seeing a question in irc (?) about why bisect refuses to
> function in a modified workspace. The rationale I had in mind was just that
> updating all over the tree while carrying along some uncommitted changes
> seemed like a good way to hit a conflict and possibly lose the pending
> changes.I was  being conservative in requiring that you don't have any
> changes to lose before starting the bisection.

I wasn't sure at first how I as a user was supposed to use bisection
(didn't used that in git or any other vcs until now), so my personal use
case was at first "I found a bug, but I don't know exactly where it
happened. Ok, I enable debug output, start bisecting and look at the
output...", which obviously won't work if enabling the debug output
requires a code change. I learned however that bisecting is even more a
perfect tool for automated bug finding and that my approach might also
be honored with a simple patch(8) call...

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