Nathaniel Smith, 2007-02-16:
It seems like always "executing" is the Right Thing for
add/drop/rename/pivot_root/whatever-else-I'm-forgetting.
I agree.
Another way to handle file removal is what darcs does: On commit, assume
that any files that are missing have been deleted. (Similar to an
implicit mtn drop --missing.)
With this model, renamings are the only operations that the revision
control system needs to be told about; deletions are inferred (just like
changes to file content). I have always found this model the most
convenient to work with.
mtn's current "files are missing, please use either mtn drop or mtn
revert" always forces me to take additional action, while a "files are
missing, I'll assume they should be dropped" would be what I want in
almost every case, with no additional action required. This is about as
good as a user interface can get. In those cases where I want something
different, I can abort.
Obviously, to make this safe, the "MTN:" hints in the commit message
editor would have to make it clear which files are being automatically
dropped.
Really, we already do the same thing for changes to file content,
without any "file contents have changed, please use either mtn
change-content or mtn revert".
Incidentally, this would also simplify the consistency constraints on
the workspace -- "missing items" would no longer be an inconsistency --
and get rid of related bugs, such as "mtn ls unknown" aborting when some
files are missing.
Christian Ohler.
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
