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

[Shawn Samuel]

Thanks for the response, Nathaniel. I will just leave it alone until
0.26 is final, and then upgrade my team to it.

Some other stuff:

My team has been using monotone since last June and it's been
terrific. We have a number of long-lived branches, and while we get
the occasional spurious merge issue, overall it's been great. --lca
was a huge time-saver in terms of reducing needless merge
resolutions. I've used many source control systems (clearcase, svn,
cvs, perforce, darcs, arch), and monotone does what I need better than
anything I've ever used.
 
We use (a slightly modified version of) the monotone buildbot to
monitor each developer's "primary" branch, as well as our dev trunk -
I got the mt buildbot code by downloading the tarball. Is it checked
in anywhere, and what is the status of incorporating that stuff into
buildbot proper? I had to upgrade the code to work against buildbot
0.70 to get some of the functionality I needed.
 
Also, as far as I can tell, there is no way to set the default key in
monotonerc. Am I just missing something, or is there a reason for
this?

cheers,
shawn
 
> > Message: 4
> > Date: Thu, 9 Mar 2006 05:34:48 -0800
> > From: Nathaniel Smith <address@hidden>
> > Subject: Re: [Monotone-devel] rename boundary failure in 0.25
> > To: address@hidden
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=us-ascii
> > 
> > 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."