On Wed, Dec 20, 2000 at 02:21:39PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > This will be especially important if we end up with a file that comes from a
> > different repository. I'm not sure whether you store the URL for a subdir
> > in "./SVN/entries" or in "subdir/SVN/entries", but we definitely mix
> > repositories on a per-directory basis. If the URL is stored in ".", then
> > they definitely have to be mixable.
>
> Yeah, I like this idea. We need the mixability. Karl? Do you agree
> that we should change this?
>
> In our `entries' file, we're currently storing ancestor_path and
> ancestor_revnum as two separate arguments. Maybe we can blend them
> together as something like
> "http://www.lyra.org/reposname/67/glorb/foo.c".
>
> (I can't remember, did we come up with a URL schema that includes tree
> revisions?)
There are *two* URLs of interest:
1) the "public" URL of the resource. this is the one that people interact
with, know about, and can visit with their web browser (which would show
the latest revision).
e.g. http://www.lyra.org/reposname/glorb/foo.c
2) the "version resource" URL. this is the revision-specific resource.
e.g. http://www.lyra.org/reposname/$svn/ver/67/glorb/foo.c
The first is (nominally) what gets stored into the entries file or displayed
to the user or whatever. But it does need a separate revision number.
The second is one of the items that I store into a property on the client
side. Every resource has one. (and is the basis for my suggestion on
revising how the commit editor calls back into the WC)
There is no "legal" way to map between them on the client. The server passes
out the URL to the version resource as an opaque string.
[ specifically, the "$svn" is changeable via a server setting, so the client
can never truly know what it is. ]
Because you cannot map between the two, both must be stored. One for the
user and the "real" location of what you're checking out, and the other for
actual operation of the system.
The version resource is specific to libsvn_ra_dav, so I'm not sure that it
should be promoted out of local-prop-storage to something that we have
special arrangements for storing.
> > [ hmm. it appears that you store ancestry for a subdir in "." ]
>
> Right. Our policy has been that a directory's ancestry info is stored
> only once: within the directory's own `entries' file in the "."
> entry. Parent `entries' files list the subdir as a child, but give no
> other info.
Um. Let me clarify: it would appear that the subdir's ancestry is stored in
the parent's entries file. e.g. it is stored in ./SVN/entries rather than
subdir/SVN/entries.
If you're intending to NOT store ancestry in ./SVN/entries, then I believe
that you have a bug :-) There is an "ancestor=" attribute in there. The
revision number only appears in the subdir/SVN/entries, though.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006