In an incredibly long, mixed-topic post, Tom Lord wrote:
>* On Tree Deltas and File Identity
>
> I asserted that node_id will not work as a mechanism for tree deltas
> because a single project tree can reasonably contain multiple files
> which have the same node_id.
>
> To expand on my assertion, let me anticipate Sander's reply: that
> node_id PLUS the history of copy/rename operations (as would be
> considered by variance adjusted patching) together add up to a
> robust notion of file identity. To respond to that anticipated
> reply: yes, the history PLUS the node_id add up to a logically
> _coherent_ notion of file identity, but a very poor user interface
> to file identity.
>
> Consider for example how I would edit a source tree absent version
> control. I'd use `cp' and `mv' and `rm' and `open(2)' and just work
> "free form" until the tree was in a state that just worked.
> Although it isn't explicit without something like an inventory tag
> mechanism, the files in my tree have logical identities. But in the
> general case, the sequence of operations I'd perform to set up those
> files won't work in svn. For example, if I copy a file, then rename
> the original: which of the two copies has the same logical identity
> as the original?
>
Both. They're different branches of the same file.
> In svn, using node_id plus history as logical file
> identity, the original but renamed file inherits the logical
> identity -- if I happen to want it the other way around, I'm
> screwed.
>
No, you have it both ways from the beginning.
> And if I happen to introduce a new node, but want it to
> have the same logical identity as an old node, I'm screwed again --
> I have to remember to check out the old node, delete it's contents
> and replace them.
>
Again, no.
> In short, I think the easiest to understand and use user interface
> comes from adding a first-class notion of logical file identity
> which is unrelated to node_id and unrelated to the history of tree
> rearrangements. I think it makes the most sense to separate out the
> physical history of versioned objects from their logical identities
> for the purpose of whole-tree patching -- to make logical identities
> something that users can attach to files/directories freely and
> rearrange arbitrarilly at will, with ease.
>
So, instead of letting the storage manager worry about file identity (as
far as merge algorithms are concerned), you'd task the user with that
burden. This shceme invites quite as many, of not more, possible user
errors than the ones you've been pointing out.
> Another way to look at this issue is to consider generating
> whole-tree changesets which people can apply to (possibly modified)
> source trees that don't have any direct relationship to a
> repository. To apply such a changeset, I need to be able to compute
> the logical identities of files in the source tree without
> consulting the repository -- the history simply isn't available. So
> representing logical identity within the svn metadata of wc plus the
> metadata in a repository doesn't fly -- not if I want to be able to
> distribute changesets to users who have copies of my distributions.
>
If I translate and extend your initial example:
1. You start with file /foo/bar, and assign it an identity, "A".
2. Jane renames /foo/bar to /foo/qux, and identifies it as "B",
because it is now "logiclly" a different file.
3. Jane copies /foo/qux to /foo/baz, and identifies it as "C"
4. Jim tries to apply a patch for the difference between (2) and (3)
a working copy that still identifies /foo/bar as "A".
> So: inventory tags, represented in the source tree.
Your inventory tags don't help at all, in this case. If node and copy
id's were represented in the patch format, then at least Jim could see
that Jane's /foo/baz and /foo/qux are related to his /foo/bar, and that
/foo/qux is in fact a rename of that file.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 15 02:09:21 2003