On Friday 28 May 2004 09:51, Branko ÄŒibej wrote:
> [...]
> the structure of the index would have look like this:
>
> (dir-id, name, [txn-id]) -> info
>
> [...]
>
> The info contains the bits and pieces attached to the path:
>
> * lock object, ACL, unversioned prop,... for this entry
> * If the entry represents a directory:
> o the dir-id of this directory, used by the next level of lookup
> o a flag indicating whether the lock/acl/prop/... is inheritable
> o maybe a flag if a lock exists anywhere _beneath_ this directory
>
This is very similar to a structure I've been thinking about lately -- used to
store copy source information. In fact, the only difference is that my vesion
used a revision number instead of txn-id (as I want to be able to access them
sequentially).
The method for using this information is just to add a copy-to row for every
copy ever made. When computing the response to a log request, we would also
merge the copy-to information of the directories along the path to the
requested node with the actual changes in the node.
So, we can consider copy-source access as another possible use/benefit of this
table... Thus implementing another oft-requested feature.
Of course, I'm ignoring the fs_fs implementation right now; so far, I haven't
thought of any efficient representation for this information in plain files
(not to mention safety guarantees and the like).
-az
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 28 10:38:28 2004