|
From: | K. Richard Pixley |
Subject: | Re: [Monotone-devel] Re: 3-way merge considered harmful |
Date: | Tue, 03 May 2005 13:26:49 -0700 |
User-agent: | Mozilla Thunderbird 1.0.2 (Macintosh/20050317) |
Nathaniel Smith wrote:
I still think there is such a format. Doesn't the v7 unix file system pretty much encapsulate this?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.)
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
[Prev in Thread] | Current Thread | [Next in Thread] |