monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] non-content conflict messages


From: Derek Scherger
Subject: Re: [Monotone-devel] non-content conflict messages
Date: Sat, 10 Nov 2007 10:33:51 -0700
User-agent: Thunderbird 2.0.0.6 (X11/20071004)

Zack Weinberg wrote:
> On 9/23/07, Derek Scherger <address@hidden> wrote:
>> I've been playing around a bit with the rather cryptic messages that
>> monotone generates on so called non-content conflicts and hopefully have
>> improved things a bit.
> 
> Cool!  Your revisions are definitely better than what we had, but I
> think they could be even better still.

I've finally put the changes I had pending on the
net.venge.monotone.cleanup.conflict-messages branch and started looking
at this again.

> diagnostic messages.  What would be good to have, though, is ancestral
> names, whenever that makes sense.

We really do need names from some common ancestor to be able to properly
report things like file X has been renamed to two conflicting names X1
and X2. It doesn't appear that we have a common ancestor handy in most
cases though and I'm having visions of having to do something like
automate common_ancestors to get one. Any suggestions?

> As a tangential nit, these are _not_ warnings, we're just using W()
> for them because we don't have a better way to do it.  Can we have D()
> [stands for "detailed error"] whose semantics are: it prints a
> diagnostic which is a hard error, but then it returns to its caller
> rather than terminating the process; furthermore, the "error: " leader
> appears only the first time D() is called, and _not_ subsequently when
> E() is called; and finally, it sets a flag in the ui object which
> causes an invariant failure if D() has been used and then the program
> attempts to exit successfully.  [Or some more elegant way of ensuring
> that code that uses D() always follows it up with an E().]

In addition to this it would be nice to have some way to include blank
lines in the output that don't contain the "mtn:" prefix since the error
for a single conflict is going to span multiple lines.

Using 'std::clog << std::endl;' directly works for this but the ui class
should probably provide something akin to the other logging macros so it
can play nicely with the tickers.

Cheers,
Derek




reply via email to

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