Proper tracking of file-level operations: rename, directories, merges

[Matthew D. Fuller]

On Fri, Oct 21, 2011 at 09:16:56AM +0200 I heard the voice of
Martin Geisler, and lo! it spake thus:
> 
> Yes, that is true -- directory renames are *defined* to mean "all
> files in foo/ was moved to bar/". As far as I can see, this is
> equivalent to actually tracking directories.

As Vincent alluded to in another mail, the problem is that you're
aliasing here.  If you defined directory renames to mean something
like "a spork landed on the moon", that would be OK (_you_ may not be,
but _it_ would ;), since that's a presumably unique event.

But there are two distinct operations a person can do; they can rename
a directory to another name, OR they can rename all the files in a
directory into another directory.  But you only have a single
representation for those, so you can't tell the difference between
them.  But to the user, they're definitely at least potentially very
different expressions of intent.

To construct one strawman of where it could matter, imagine a tree
where you have two dirs like "unchecked/" and "checked/", and you
move the files from one to the other after a person has examined them.
If you track as hg does, and somebody checks and moves all the files
from one to the other for the first time, then any later merges would
wind up moving new files in unchecked/ right into checked/ without the
user having checked them (or even possibly noticing it's happened).


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.