[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Path lookup table (was: Re: Locking design (was Re: svn commit: r9885 - trunk/notes))

From: Alon Ziv <alonz_at_nolaviz.org>
Date: 2004-05-28 10:32:24 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.