Philip Martin wrote:
>"Bill Tutt" <rassilon@lyra.org> writes:
>
>
>
>> John commits an update to create /foo as Foo.0.TxnA.
>>
>>/foo now has an empty ancestry set.
>>
>> Barney commits a change to /foo as Foo.0.TxnB.
>>
>>/foo now has an ancestry set of {Foo.0.TxnA}
>>
>> Charley commits a change to /foo as Foo.0.TxnC.
>>
>>/foo now has an ancestry set of {Foo.0.TxnA Foo.0.TxnB}
>>
>>
>
>We don't have to explicitly store the above do we? I think it's
>implied by the current node history.
>
How we store it is not the question here; obviously a lot of the
ancestry info can be either compressed or derived. But all the info has
to be accessible somehow.
>Some merges involve reversing a particular ancestry set. I think we
>will need to store whether a merge added or removed a particular
>ancestry set.
>
Of course. A reverse merge woud do that, and in that case the
information derived from node history woudl be wrong. :-)
>I'm interested as to how we would implement this. Are the ancestry
>set IDs, the things like Foo.0.TxnA, visible to the client? Is it
>done entirely in the client using properties, or does the Subversion
>filesystem get involved?
>
Good question. I wish I knew the answer...
--
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 Sun Dec 8 22:33:33 2002