Greg Hudson wrote:
>On Fri, 2004-06-25 at 09:02, email@example.com wrote:
>>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,
>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
>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
>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
/me waits for his brain to unscramble
>This question can wait until the promised 2.0 metamodel document,
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jun 25 18:33:21 2004