[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
taken".
These are now tests 80-82 :-)
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen
- [Monotone-devel] db query error on propagate, monotone 0.16, Georg-W. Koltermann, 2005/01/04
- [Monotone-devel] Re: db query error on propagate, monotone 0.16, graydon hoare, 2005/01/04
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Matthew A. Nicholson, 2005/01/04
- Re: [Monotone-devel] db query error on propagate, monotone 0.16,
Nathaniel Smith <=
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Georg-W. Koltermann, 2005/01/05
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Nathaniel Smith, 2005/01/05
- [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Georg-W. Koltermann, 2005/01/17
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/17
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Georg-W. Koltermann, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Georg-W. Koltermann, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/21
Re: [Monotone-devel] db query error on propagate, monotone 0.16, Nathaniel Smith, 2005/01/05