Re: [Monotone-devel] Tailor

[Nathaniel Smith]

On Fri, Oct 13, 2006 at 11:37:54AM +1000, Brian May wrote:
> which makes me nervous because the add doesn't come until after the
> rename.
[in the status output]

Don't worry.  In monotone changesets, everything "happens at once".
Or another way to put it, really you have the old tree and the new
tree, and the changeset describes the relation between them, not a
sequence of operations to be executed sequentially to produce one from
the other.

We do intentionally list them out in an order that will tend not to
make people freak out even if they are thinking sequentially (e.g.,
listing deletes before adds, instead of vice-versa), but that's
nothing to do with how things actually work.

> address@hidden:~/monotone/junk$ mtn update --revision 
> 176f0879aa85be219a61b2c47303ef778faf09c5
> mtn: selected update target 176f0879aa85be219a61b2c47303ef778faf09c5
> mtn: renaming statistics/.arch-ids/apache.id to .arch-ids/apache.id
> mtn: renaming reliability/.arch-ids/check_disks.id to .arch-ids/check_disks.id
> mtn: renaming reliability/.arch-ids/checkisdn.id to .arch-ids/checkisdn.id
> mtn: renaming statistics/.arch-ids/count_spam.id to .arch-ids/count_spam.id
> mtn: renaming statistics/.arch-ids/processmail.id to .arch-ids/processmail.id
> mtn: renaming statistics/.arch-ids/squid.id to .arch-ids/statistics.id
> mtn: renaming statistics/.arch-ids/webalizer.id to .arch-ids/webalizer.id
> mtn: renaming statistics/apache to apache
> mtn: renaming reliability/check_disks to check_disks
> mtn: renaming reliability/checkisdn to checkisdn
> mtn: renaming statistics/count_spam to count_spam
> mtn: renaming statistics/processmail to processmail
> mtn: adding statistics
> mtn: renaming statistics/webalizer to webalizer
> mtn: dropping update_vacation
> mtn: dropping tla/make_signed
> mtn: dropping tla/diff_changeset
> mtn: dropping tla/.arch-ids/make_signed.id
> mtn: dropping tla/.arch-ids/diff_changeset.id
> mtn: dropping statistics/.arch-ids
> mtn: error: could not remove '_MTN/tmp/16'
> mtn: error: Directory not empty
> 
> oh yuck. It looks like mtn just allowed me to commit a changeset that
> it can't handle.
> 
> Some other comments:
> 
> * There is nothing corrupt in the original baz repository, baz has no
> problems coping with it.
> 
> * monotone probably shouldn't allow me to commit a changeset that it
> can't cope with.

Hmm, the definition of "cope with" is ambiguous here.  In the general
sense, monotone certainly will _not_ allow you to commit a changeset
that it can't cope with.  In fact, there is exactly one byte sequence
describing each possible legal change to a tree, and monotone will
never store into its database any other byte sequence.  Seriously, 

However, monotone's workspace update logic can run into problems when
monotone's idea of what the workspace contains turns out to disagree
somehow with what the filesystem thinks.  Since filesystems are
horrible creatures full of race conditions, this can be tricky.  The
most common problem, and the one you ran into here, is that a
directory may contain unversioned files that are "invisible" to
monotone.  When monotone attempts to apply a changeset to the
workspace that removes that directory, it eventually notices the
problem when it's already in the middle of its work.  At that point it
basically can either silently trash all those sunversioned files, or
error out, leaving the workspace in an inconsistent state.  We do the
latter.

Better would be to have some sort of rollback, or moving the offending
files out of the way while preserving them, or something like that...
but getting a general solution is difficult, and no-one has worked out
a design yet.  Some of the ideas that might be helpful are on the
wiki:
  http://venge.net/monotone/wiki/CaseInsensitiveFilesystems
  http://venge.net/monotone/wiki/Win32DeviceFiles
  http://venge.net/monotone/wiki/NonMergeConflicts

-- Nathaniel

-- 
Electrons find their paths in subtle ways.