monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] problem with update after merge (was: Re: db query


From: Nathaniel Smith
Subject: Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16)
Date: Mon, 17 Jan 2005 14:40:30 -0800
User-agent: Mutt/1.5.6+20040907i

On Mon, Jan 17, 2005 at 02:44:22PM +0100, Georg-W. Koltermann wrote:
> Am Mittwoch, den 05.01.2005, 02:43 -0800 schrieb Nathaniel Smith:
> > Everything you describe should work as of
> >   4eda564e05108d2026c0cfb77733188790eeb754
> > in the monotone mainline, now.
> 
> Yep, confirmed as of 0b17415d7aa112060e8ead9ae7a486510dc61a9d.

Great.

> There is one anomaly, though.
> 
> I have one directory with the main branch checked out, containing only
> the first revision at first.
> 
> I check out that main branch to another directory, create the
> r5-features branch there, and merge it back into the main branch.
> 
> Then I go back into the first directory with the main branch (prior rev)
> checked out, and do a "monotone update".  Since I recently merged
> r5-features into main I expect of course that the directory should be
> updated to contain that merged version.  It doesn't do that, instead it
> prints:
> 
>         monotone: warning: update edge 
> 5419a30854a07e05a0a6c05f353ee9f6b80014f9
>         -> b4869a21118e845b3da273aed0dc4c6ecbb0a6d4 ignored since it exits
>         branch test-main
>         monotone: already up to date at 
> 5419a30854a07e05a0a6c05f353ee9f6b80014f9

Huh, weird.  I've added a test for this, but I can't reproduce it --
seems to work fine.  Can you give more details?

> If I checkout the main branch into a fresh directory I do get the
> correct version, the problem is only with "monotone update".
> 
> Do you think that could be fixed?

In general, 'update's logic for picking which revision to update to is
a bit broken right now; I guess this might be another edge condition
it doesn't handle right.  It's only the logic that chooses the target
that currently doesn't work right, so you can always perform an update
by picking which revision you want and doing an explicit 'update
<revision>'.

There's a semi-detailed description of how to fix the update target
algorithm generally in tests/t_update_ambig.at, in case anyone feels
like attacking some bugs ;-).

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco




reply via email to

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