Re: [Monotone-devel] Re: 3-way merge considered harmful

[K. Richard Pixley]

Nathaniel Smith wrote:

> The problem is that a sufficiently clever format does not seem to
> exist.  (I won't go into details, because there are lots and lots of
> things you can try, and we did.)  So you have to merge trees directly,
> which is possible, it just takes different algorithms, and these days
> those algorithms don't look as hard as they once did.  (Not that
> they're easy, but not nearly so hard.)
>  
I still think there is such a format.  Doesn't the v7 unix file system 
pretty much encapsulate this?

Each "directory" is a file containing records, each record contains a 
filename + inode number.

The inode table points to file extents, protections, a link count, and 
perhaps back pointers, etc.  Atomic operations include "link" and 
"unlink" and possibly "rename".

If you collapse all of the directories into an archive resembling a 
normalized "ls -iR", then I believe that you can indeed translate 
textual changes into file system operations.  You'll need to be careful 
about the ordering so you make the new links before removing the old 
ones, but that should be straightforward.  Even the archive isn't 
strictly necessary.  Since we're talking about a system with atomic 
commits of changesets, top-down, bottom-up, doesn't really matter.  You 
do stand the possibility of committing a partial tree with no path to 
the root.  However, since this partial tree can't be accessed in any of 
the normal ways, short of commiting a change set which reconnects it to 
the root of an existing branch, I submit that it can't possibly create 
any conflicts you aren't already solving.

Clearcase does something comparable.  I can even commit manual surgery 
on a directory by manually linking an arbitrary inode into it with an 
arbitrary name.

I'm surprised that monotone isn't doing this already.  Of course, you'd 
need to find some identifier to stand in for the inode number...

--rich