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

storing URLs in SVN/ (was: Re: absolute paths)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-20 21:06:05 CET

On Wed, Dec 20, 2000 at 01:54:55PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>
> > Agreed, but you should think in terms of URLs rather than "absolute paths".
> > Absolute with respect to what? That's an oxymoron, of course... absolute
> > means it isn't relative. But the point here is that "/products/..." is NOT
> > absolute. "http://www.lyra.org/products/glorb/..." *is* absolute.
>
> Ah, yes, of course. There's a file in the SVN/ administrative dir
> called `repository'. I believe it will simply contain a URL to the
> webdav server: "http://www.lyra.org" or whatever. Meanwhile, the
> various `entries' files contain paths within the filesystem such as
> "/products/glorb/foo.c". The client uses the `repository' file to
> open an ra-session, as you suggest, and from there uses the paths
> within the `entries' files to drive editors.
>
> So I think we're in agreement on this one. :)

Why separate that stuff? Why not just store the URL? The repository_URL
passed to RA->open is simply the URL associated with the topmost, common
directory.

The separate "repository" and "path" is following CVS's pattern for no good
reason... it is an artificial separation.

"http://www.lyra.org/products/glorb/foo.c" is the path. I'd say that we
simply store it that way.

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.

[ hmm. it appears that you store ancestry for a subdir in "." ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

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.