Goals: generality

Tom Lord lord at emf.net
Tue Apr 29 22:49:40 CDT 2003




> 2. I like the idea of nesting, making a node either contents or, a set
>    of nodes. This could imply that a file could consist of {contents,
>    meta-data} where meta-data in turn could consist of filename among
>    other things. A move operation would thus be a change of filename?


What problem are you trying to solve?  What's "a node"?  Why is it
advantageous to use "nesting"?

On the one hand, it's a fine instinct to look for a small set of
primitive concepts that "everything else" can be reduced to -- but on
the other hand, huh?   Why _these_ concepts that you suggest?   What's
the win?  I don't see it.

Let's suppose that filenames are reduced to "just more metadata".  Ok,
perhaps that simplifies the patch format in some abstract sense -- but
won't any implementation still have to treat filenames differently
from all other meta-data?  Won't filename diffs be generated by
different code than, say, permissions diffs?  Won't they be applied by
completely different code?  Won't, in effect, changeset-reading
programs have to "pick apart" any unified representation into separate
cases?  Is there any actual use for a generic treatment of metadata in
which, say, permissions and filenames are "the same kind of thing"?
What's the value of this abstraction?

(BTW: you aren't alone here -- some otherwise skilled ( :-) revision
control implementors have thought along the same lines -- I just don't
see the payoff here, so I'm being kind of an ass about it.)

FWIW, changesets in arch handle renames this way:   There's a 
partial inventory of ORIG and MOD, where an inventory is a list of
pairs:

	<path>	<inventory-tag>

Where the same "<inventory-tag>" occurs in both the ORIG and MOD
inventories, but with a different "<path>" -- that indicates a rename.

So, in effect, all the renames are summarized as a permutation of
logical objects/paths, from which the patch-applier gets to infer the
set of file system ops to appropriately rearrange things.  That's a
handy way to summarize, for exaple, the swapping of two names without
having to record a rename through a temporary file.  Other meta-data
(specifically, file permissions) is treated completely differently.
In the code, there would be no advantage to trying to combine
filenames with other meta-data -- just the opposite -- it's convenient
that they are distinct.  It's completely separate parts of the code.

-t




More information about the changesets mailing list