Re: [Monotone-devel] rename boundary failure in 0.25

[Nathaniel Smith]

On Wed, Mar 08, 2006 at 10:43:59AM -0500, Shawn Samuel wrote:
> On 0.25, below is a simple test case that causes monotone 0.25 to blow
> up.
>
> setup branch1
> add a.txt, b.txt
> commit1
> rename a.txt c.txt
> commit2
> rename b.txt a.txt

BTW, monotone is perfectly happy for those two renames to happen in
the same commit.

> commit3
> 
> co -r commit1
> edit a.txt
> commit4 to branch2
> 
> propagate branch2 branch1
> 
> To summarize, I renamed a->c, b->a (in two separate commits). If I
> edit "a" in a pre-rename version and commit to a separate branch, the
> propagate blows up as below. Same thing if I commit to the same branch
> and merge. If I modify "b", it works fine.
> 
> The implication is that monotone can't tell if that change to "a" is
> meant to apply to "c" or "a" in the first branch. Since there is no
> sequencing implied to changes in parallel histories, we can't tell if
> the rename in one branch should happen before or after the
> modification of the file in the other.

On the contrary, looking at the temporary variables in that debug
output, 0.25 appears to have figured out exactly how to do that merge
correctly.  (I.e., giving you a tree that looks like branch1, but with
branch2's edit applied to c.txt.)

Then it blows up, for some reason -- perhaps some bug in the
consistency checking.

I'm not sure what you're hitting here, in detail.  I can tell you what
the general problem is -- it turns out that when we first implemented
rename support, we were a little... overambitious.  At the time,
basically nothing was known about how to handle renames (and related
issues) correctly, and we eventually realized that there were some
very subtle but extremely deep problems with our approach.  So most of
the time it handles renames brilliantly, and then every once in a
while you hit some case where it decides everything it did was wrong
(sometimes correctly, sometimes not), and blows up.  The code itself
has been patched and re-patched to handle most of these cases, but at
this point it's a big mess, no-one wants to touch it, and the
remaining cases are horribly obscure or not even possible to fix in
principle.

So, this probably sounds pretty dire.  It sounded much worse a few
months ago, when that was the end of the story :-).  These days,
though, we are getting closer and closer to a full stable release of
the shiny new versioning/merging core -- this is why 0.26 is such a
big deal.  So far, in a few months of use, the 0.26 pre-releases have
been rock-solid.

> So, two questions -
> 1) Do monotone developers agree that this is how it should work?

Yes.

> 2) How do I fix this in the meantime? Will "mt disapprove" (oops, just
> outed my naming preference) fix it, or will it just further confuse
> monotone? Is there some other way? Fortunately, this rename was in a
> side-branch, so it's not a really big deal for my team, but I would
> like to know what to do.

I'm not sure exactly what is best for you.  As a general comment,
since the next release will have a much improved versioning core, your
goal should be just to get something that works well enough to keep
you going until then; I wouldn't worry about making sure you have "the
Right Solution".  Anything that lets you continue is fine.

Some options:
  -- rename one of the files back, try disapproving, etc. -- do this
     in a temp database, and see if any of the things you try work.
  -- go ahead and upgrade to 0.26pre now.  This involves a major data
     migration, and all users have to upgrade together -- see
       http://venge.net/monotone/NEWS.pre
       http://venge.net/monotone/UPGRADE.pre
     for initial documentation on this process.  However, note that
     there may (or may not) be another, similarly disruptive change
     between the current pre-releases and a final 0.26 release;
     discussion is ongoing.
     If you do this, you will want to watch the mailing list and
     possibly IRC channel; the prereleases are supported (monotone
     development itself uses them, so we sort of have to... :-)), but
     this support may assume that people are a little plugged in to
     the process :-).
  -- ignore it until 0.26 is released

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."