You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bill Tutt <bi...@microsoft.com> on 2002/06/13 23:21:16 UTC
Storing Paths Related Question
Currently we store paths as the quite sensible string representation:
"/trunk/subversion/libsvn_fs/....".
However, can anybody think up useful/frequent access patterns where the
following representation might be more optimal, or make certain code
paths cheaper by being able to take advantage of such path storage? If
so, which code paths does this help?
/NR1.C1.T1/NR2.C1.T1/NR3.C1.T2/.....
Or to put the idea in abstract math like speak: an ordered sequence of
NodeRevisionPKs without any named attached to each NodeRevision.
Thoughts?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Storing Paths Related Question
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> Bill Tutt wrote:
>
> >Currently we store paths as the quite sensible string representation:
> >"/trunk/subversion/libsvn_fs/....".
> >
> > [...]
>
> It all depends on where you'd want to store such paths. The filesystem
> doesn't store _any_ paths today, IIRC, and you couldn't very well use
> them in the URLs (except for the opaque versioned-resource thingies,
> don't know if that would do any good).
Filesystem stores copy-from paths (in the `copies' table).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Storing Paths Related Question
Posted by Branko Čibej <br...@xbc.nu>.
Bill Tutt wrote:
>Currently we store paths as the quite sensible string representation:
>"/trunk/subversion/libsvn_fs/....".
>
>However, can anybody think up useful/frequent access patterns where the
>following representation might be more optimal, or make certain code
>paths cheaper by being able to take advantage of such path storage? If
>so, which code paths does this help?
>
>/NR1.C1.T1/NR2.C1.T1/NR3.C1.T2/.....
>
>Or to put the idea in abstract math like speak: an ordered sequence of
>NodeRevisionPKs without any named attached to each NodeRevision.
>
>Thoughts?
>
>
It all depends on where you'd want to store such paths. The filesystem
doesn't store _any_ paths today, IIRC, and you couldn't very well use
them in the URLs (except for the opaque versioned-resource thingies,
don't know if that would do any good).
Converting between the two representations costs the same in both
directions, so that wouldn't be an issue.
--
Brane Čibej <br...@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