On Fri, 2004-06-25 at 09:02, kfogel@collab.net wrote:
> brane@tigris.org writes:
> > Another note about terminology:
> >
> > Object or Entity ID is usually used to refer to what we call node IDs -- a
> > single identifier that logically groups related versions of the same object.
>
> Note that in issue #1525, we are using "Entity ID" as a synonym for
> "node revision ID".
Uh, not quite. Issue #1525 proposes that entity IDs be isomorphic to
node revision IDs, not synonymous with them. (Specifically, we use a
change count instead of the transaction ID.)
> In other words, an Entity ID doesn't refer to a
> logically related group of objects, but rather to *one* object (which
> may happen to be reachable from different paths/revisions in the svn
> filesystem).
Correct.
brane wrote:
>> We think we can generate this thing using the filesystem's NodeId, CopyId,
>> and (get this) the PredecessorCount (from the skip-delta code!).
> So you propose to count the predecessors every time. How boring. Why not just
> take the (single logical immediate) predecessor's "change count" (version
> number!) and increment it. I suppose the obvious solutions are too complicated,
> what :-)
No, the obvious solutions are already done. We already store a
predecessor count field in the node revision skel.
> Another 2.0 change is that branch IDs should be unique within node IDs
I don't think you said this like you meant to say it. Branch IDs are
already unique within node IDs; if they weren't, we would lose horribly
when someone committed a change to the same file on two different
branches and wound up with two node revisions with the same node
revision ID.
Perhaps you meant to say that copy IDs should be subsidiary to node IDs,
instead of having an independent cross-node-ID existence like they do in
the current code. That's how I would have done it in the first place,
but (a) perhaps there's some reason for the conservative copy ID
allocation in the current code, and (b) I don't understand how making
copy IDs subsidiary to node IDs makes it easier to implement renames.
This question can wait until the promised 2.0 metamodel document,
though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 16:43:04 2004