monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] new bisect command


From: Derek Scherger
Subject: Re: [Monotone-devel] new bisect command
Date: Mon, 23 Nov 2009 22:57:57 -0700

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.
 

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?

Yeah, that's a good idea. I'm not particularly fond of the current implicit assumption that good" is assumed to be an ancestor of "bad" at all. If we determine which is an ancestor of the other, or if there is no ancestry relationship I should be able to sort this out as well.

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?

 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.

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.

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.

Thanks for the comments.

Cheers,
Derek


reply via email to

[Prev in Thread] Current Thread [Next in Thread]