[Monotone-devel] noclobber hooks for update and checkout

[Derek Scherger]

One of the things I'm using monotone for is tracking files in my home
directories (things like my ~/.xemacs/ directory and such) and
configuration files in directories like /etc. These files appear in
various states on different machines and I find VC a nice way to keep
them in sync. 

I think I've seen other people on this list or on #monotone talking
about doing similar things and who have also noticed that on checkout
and update monotone silently overwrites any files that might be "in
the way".

I've never really liked the cvs approach to this problem, which
requires blocking files to be manually removed before checkout or
update will touch them. I typically move them out of the way, do the
update or checkout and then move them back to see what the blocking
copies looked like. This is rather tedious and I'd like to have it
done automatically. (i.e. leave blocking files alone but update the
working copy administration information so that such files can be
compared against their associated database versions)

I've finally managed to get around to implementing something to do
this and the results are available on the net.venge.monotone.noclobber
branch via netsync at www.echologic.com.

In summary, I've added the following two lua hooks:

        function delete_dropped_file(name) return false; end
        function replace_existing_file(name) return false; end

The first controls whether update deletes files that have been dropped
and the second controls whether update and checkout overwrite
(i.e. clobber) pre-existing files.

The current monotone behavior is essentially what you get with both of
these hooks returning true. i.e. update deletes files that have been
dropped and both update and checkout silently overwrite any files they
find in the way.

With these hooks set to return false update will simply not delete any
dropped files and will leave them behind to be dealt with manually.
Both update and checkout will not overwrite pre-existing files and
instead leave them as they are. The net effect of this is that
immediately after an update or checkout some files may appear as
though they have been modified allowing for any changes to be
considered, adjusted and committed or reverted as required.

I had considered other options for the replace_existing_file hook so
that it would be possible to configure update and checkout to fail if
they were blocked by an existing file. However, failing properly is
rather complicated -- no files in the working copy should really be
touched until all updates have been successfully applied. At the
moment, I believe that failing in the middle of update/checkout will
leave things in a somewhat inconsistent state. Changes before the
failure will have been applied to files in the working copy and
changes after the failure will not have been applied and MT/manifest
will not have been updated.

This change also fixes one small bug (or inconsistency) that I've
found with renames. If the target of a rename exists, update will fail
in boost::filesystem::rename rather than replacing the rename
target. Now, if the replace_existing_file hook returns true any
existing rename target is removed before the rename is attempted. If
this hook returns false, the delete_dropped_file hook is checked to
see whether the rename source gets deleted or not.

I think this change also addresses the one declined bug on savannah
(#5247).

--
Cheers,
Derek