Re: [Monotone-devel] Invariant Failure while Merging

[Nathaniel Smith]

On Wed, Feb 02, 2005 at 11:07:13AM -0500, address@hidden wrote:
> > I haven't seen this particular error before, so it looks like a new
> > bug.  Would it be possible to make available your database (if the
> > information in it isn't proprietary or the like), or failing that, the
> > output of running the same command again, passing the --debug switch
> > on the command line?  That would be very helpful in tracking down what
> > exactly is going wrong.
> 
> We are perhaps fortunate that there are no IP concerns for us to worry
> about.  A copy of our database is available at
> http://cs.swarthmore.edu/~mstone/backup.db and at cs.swarthmore.edu:6000
> over netsync.  The branch name is "edu.swarthmore.engin.shadowfax.s05".

I'm sorry, I just realized that I had forgotten to reply to this!

It looks like it _is_ another case of a bug we know about, and that is
high on my priority list for 0.17.  (Same as Peter Simons's rename
bug, for those following along at home...).  In the mean time, running
"db rebuild" with a recent monotone checkout _should_ get things
unwedged; let me know if it doesn't.

> The database was created with monotone-0.16.  We were also having a
> problem with new heads being created on every commit that was solved by
> moving to the most recent (as of a when I sent my first email) development
> branch.

Hmm, not sure what you mean here.  Commit always creates a new head, I
mean, that's what it's there for...

Oh, hmm, looking at your database, though, I have a guess what was
going on... there are a few facts to keep in mind
  - you can always commit against any revision
  - the only thing that changes which revision your working copy is
    based off of is "update"
  - "merge" creates a new revision
So if you have
   A --> B  (with a checkout of B lying around)
and then someone else commits against A
   A --> B
    \
     --> C
and you merge
   A --> B ---
    \         \
     --> C --> D
then your checkout of B will still be a checkout of B; and if you make
changes in it and commit them, you will get another child of B, E:
   A --> B -----> E
    \         \
     --> C --> D
and now have 2 heads again.

The solution is, after merging, consider updating :-).  This isn't the
default because update, in any VCS, is kind of a scary operation --
it modifies your working copy, and your working copy is exactly that
work that you _haven't_ gotten squirreled away into the VCS yet where
you know it's safe.  And in Monotone, we don't have any arbitrary
requirement for updating, like e.g. CVS does -- if you have some
changes you want to merge into mainline, you might as well commit them
(thus saving the version you worked on and tested, etc. for
posterity), and _then_ merge them with whatever else has been going
on, instead of using 'update' to merge (losing forever the version
that you were working and testing on, and possibly trashing your
changes) _before_ committing.  So, while there are definitely
exceptions, my rule of thumb is that all else being equal I update
whenever I have no local changes.

Hmm, talking about all this, I wonder if it'd be useful for 'update'
to squirrel away a pristine copy of your pre-update working directory
under MT/ somewhere, so we could provide a revert_update command...

IIRC you also had a problem with netsync... would it be possible to
post details of that here, so we could see about reproducing it?

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff