Greg Hudson <ghudson@MIT.EDU> writes:
> > That code is a bit out-of-date. Try writing a delta construction
> > algorithm.
>
> This was a little cryptic, but I think I understand. A client wants
> to update from rev X to rev Y, and you have to generate an edit. As
> part of the edit, you have to get from one version of a directory to
> another, which means for each entry that changed, you have to apply a
> sub-delta, and to do that you want to choose the most closely related
> ancestor to make a delta from.
Exactly.
> I've been wondering whether directories need to be handled differently
> from files, such that the history of directory operations is kept
> rather than just (possible optimized) storage of the contents at each
> revision. This sort of encompasses Greg Stein's point that we could
> lose information from a copy or rename operation because we don't keep
> track of where a new entry was copied or renamed from. But that's a
> very complicated proposition.
Exactly.
Modulo any emotional attachment I may have to the current filesystem,
I'm open to suggestions for fundamental changes, as long as they
retain the essential idea here: a simple support structure, easily
understood, and whose integrity we can easily design to protect, with
generic metadata mechanisms (!) (property lists, whatever...), on
which we can build the groovy features we want (genetic merging, etc).
Received on Sat Oct 21 14:36:21 2006