[Top][All Lists]

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

Re: [Monotone-devel] db query error on propagate, monotone 0.16

From: Nathaniel Smith
Subject: Re: [Monotone-devel] db query error on propagate, monotone 0.16
Date: Tue, 4 Jan 2005 21:43:31 -0800
User-agent: Mutt/1.5.6+20040907i

On Tue, Jan 04, 2005 at 07:12:46PM +0100, Georg-W. Koltermann wrote:
>         hunter[135]$ monotone propagate r5-features main
>         monotone: propagating r5-features -> main
>         monotone: [source] 8459c7f42bc9f007e54e6447e29b266cf24ee274
>         monotone: [target] 5419a30854a07e05a0a6c05f353ee9f6b80014f9
>         monotone: common ancestor 5419a30854a07e05a0a6c05f353ee9f6b80014f9 
> found
>         monotone: trying 3-way merge
>         monotone: discarding debug log
>         monotone: fatal: std::runtime_error: db query [SELECT data FROM 
> revisions WHERE id = '%q']:  wanted 1 columns, got 0

There seem to be several things going on here.

Firstly, the proximal cause of the problem is that we have a graph
like A -> B -> C and we're trying to merge A and C.  This is
ill-defined, and what's more, untested.

Doing this uncovers two bugs, when we try to calculate the changeset
from A to A (since A is chosen as the common ancestor):
  - in calculate_composite_change_set, we should probably notice the
    case where ancestor == child and return an empty change_set
    immediately.  But we don't.
  - this means that we get to find_subgraph_for_composite_search
    with ancestor == child.  This triggers a bug that I think can
    probably be triggered on valid input as well -- this is yet
    another routine that doesn't check for null identifiers, and will
    happily search off the end of the graph.  The only thing special
    that causes it to happen in this case is that if you search
    backwards from A looking for A, you will never find it and
    eventually hit the end of the graph.

If we fix these, we still have a problem, in that we don't actually
_want_ merging A and C to work.  That would create the silly graph
A -> B -> C -> D, A -> D, which has no sensible interpretation.

However, propagate should still have done something useful in this
case.  I think what we want is, when the user does propagate B A:
  - if head(B) is a proper descendent of head(A), then don't perform a
    merge, but do add a branch A cert to head(B).
  - if head(B) is an ancestor of head (A), or head(B) == head(A), then
    don't perform a merge or do anything else except print a message
    like "branch A is up-to-date with respect to branch B; no action

These are now tests 80-82 :-)

-- Nathaniel

Eternity is very long, especially towards the end.
  -- Woody Allen

reply via email to

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