Greg Hudson wrote:
>On Fri, 2004-06-25 at 09:02, kfogel@collab.net wrote:
>
>
>>brane@tigris.org writes:
>>
>>
>
>>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.
>
>
Ah, good. I misunderstood Mike's original post, then.
>>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.
>
Yes, that's what I meant.
>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,
>
The idea was to get a meaningful branch number, that is, all node-revs
on the same branch would have the same branch ID (even if they didn't
belong to the same node!). Of course that turned out to be a monstrous
blunder.
>and (b) I don't understand how making
>copy IDs subsidiary to node IDs makes it easier to implement renames.
>
>
In the current scheme, you can't simply relink a moved (directory)
node-rev into another directory, because the copy-id generation
algorithm will use the ID from another branch to generate copy-ids for
future versions of subsidiary files, thus possibly generating duplicate
node-rev-ids. Ooof.
/me waits for his brain to unscramble
>This question can wait until the promised 2.0 metamodel document,
>though.
>
>
Oh yes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 18:33:21 2004