You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/05/29 23:54:26 UTC
repository URLs (was: Just say no to collections: moving wc meta-data out of the wc)
On Wed, May 29, 2002 at 11:41:38AM -0500, Karl Fogel wrote:
> cmpilato@collab.net writes:
> > I've always been under the impression (and pleased with that
> > impression) that were going to do just this; store the FULL url, and
> > store the repos url. There are precious few operations at this stage
> > that actually need the repos url,
*Nothing* needs the repository URL. All we need (in the new commit/update
code to handle mixed-repository working copies) is a repository identifier
that can be compared for equivalency. It would be perfectly acceptable to
say that the repos IDs associated with three WCs are "a", "a", and "b". The
first two WCs come from the same repository, and the third from another.
> > but everything needs the full
> > url...so we burden ourselves with the calculation overhead every time
> > we need the full url? The subtraction to get a relative url is
> > extremely straightforward and cheap (drop a `\0' at strlen (repos_url)
> > + 1).
Conversely, since we never need a repository URL, we never need a relative
URL either.
We can take two approaches towards identifying the repository.
1) The identifier is private (an opaque string).
For this case, the RA layer will provide an identifier back to the WC of
its own choosing. For ra_dav, this would probably be the URL of the VCC,
and I could use it in various scenarios to optimize out some roundtrips.
ra_local would just use the raw filesystem path (e.g. /var/repos/test)
2) The identifier is public (meaning it has specific semantics associated
with it, and can probably be presented to the user).
In this case, we don't let the RA layer define what it means, but we
impose a meaning. This would probably be "the URL corresponding to the
root of the repository." For ra_dav, this would be an http(s) URL. For
example, the SVN repository would be http://svn.collab.net/repos/svn/.
ra_local would be file:///var/repos/test/
I can see advantages for either approach. My technical preference would be
for option (1), but I think that option (2) has certain advantages for
users. So... I'm not even sure which way I lean on this. Hopefully, somebody
will come up with some really good arguments for one or the other.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository URLs (was: Just say no to collections: moving wc meta-data out of the wc)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, May 30, 2002 at 10:08:44AM -0500, Ben Collins-Sussman wrote:
>...
> How about the fact that option (2) allows users to just casually
> browse a repository in their browsers? If I run 'svn info' on some
> resource in my working copy, I'd much rather see a hyperlink I can
> just click on, rather than some opaque repos identifier.
You already have a hyperlink to the resource itself. You just don't have one
to "the base of the repository." And if the ID was opaque, then 'info'
certainly wouldn't be showing it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository URLs (was: Just say no to collections: moving wc meta-data out of the wc)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > But that's not really the Subversion model; in
> > Subversion, the container *is* the versioned resource, and the
> > individual file or directory is just a piece of it. It makes perfect
> > sense to want to know where the versioned resource starts in that model,
> > even if the core Subversion operations don't generally need to.
>
> Hmm. Not entirely sure about this, but I can see it. For example, we talk
> about /trunk and /tags and /branches all the time. We're referring to
> particular locations *within* a repository. If the location of the
> repository isn't clear, then it is hard to talk about the relative paths
> within that repos. For example, do we talk about /svn/trunk, or /trunk? If I
> don't tell you that the repository is http://svn.collab.net/repos/svn/, then
> you can't answer the question.
How about the fact that option (2) allows users to just casually
browse a repository in their browsers? If I run 'svn info' on some
resource in my working copy, I'd much rather see a hyperlink I can
just click on, rather than some opaque repos identifier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository URLs (was: Just say no to collections: moving wc meta-data out of the wc)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 29, 2002 at 08:34:43PM -0400, Greg Hudson wrote:
> On Wed, 2002-05-29 at 19:54, Greg Stein wrote:
> > 1) The identifier is private (an opaque string).
> > 2) The identifier is public (meaning it has specific semantics associated
> > with it, and can probably be presented to the user).
>
> Either would work, I think, but I prefer (2). Things may not generally
> need the URL of the root of the repository, but it doesn't really hurt
> to give it to them. And (1) is conceptually more complicated, because
> the client and the server think of the identifier differently, whereas
Hmm. I'm not sure the server would necessarily have an internalized
identifier. It certainly *could*, but our current server (or ra_local) code
doesn't really have that.
But that isn't really here nor there...
>...
> I imagine some GUI presentation tools would appreciate having the
> repository URL handy. For instance, you might want to show how a
> working directory relates to the root of the repository it lives in.
Yup.
> Philosophically speaking, I'm betting that you prefer (1) because you
> instinctively think of a repository as a collection of versioned
> resources, because that's how DeltaV works. You don't much like the
> idea of being able to poke at where the repository starts because you
> want everyone to think about the individual resource and not the
> container it lives in.
Bing! :-)
Yah... that is exactly what I was referring to when I said "from a technical
standpoint."
> But that's not really the Subversion model; in
> Subversion, the container *is* the versioned resource, and the
> individual file or directory is just a piece of it. It makes perfect
> sense to want to know where the versioned resource starts in that model,
> even if the core Subversion operations don't generally need to.
Hmm. Not entirely sure about this, but I can see it. For example, we talk
about /trunk and /tags and /branches all the time. We're referring to
particular locations *within* a repository. If the location of the
repository isn't clear, then it is hard to talk about the relative paths
within that repos. For example, do we talk about /svn/trunk, or /trunk? If I
don't tell you that the repository is http://svn.collab.net/repos/svn/, then
you can't answer the question.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository URLs (was: Just say no to collections: moving wc
meta-data out of the wc)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2002-05-29 at 19:54, Greg Stein wrote:
> 1) The identifier is private (an opaque string).
> 2) The identifier is public (meaning it has specific semantics associated
> with it, and can probably be presented to the user).
Either would work, I think, but I prefer (2). Things may not generally
need the URL of the root of the repository, but it doesn't really hurt
to give it to them. And (1) is conceptually more complicated, because
the client and the server think of the identifier differently, whereas
in (2) they think of it the same way. (That kind of complexity is a
good thing when there is a reason to hide information, but I don't see
any reason here.)
I imagine some GUI presentation tools would appreciate having the
repository URL handy. For instance, you might want to show how a
working directory relates to the root of the repository it lives in.
Philosophically speaking, I'm betting that you prefer (1) because you
instinctively think of a repository as a collection of versioned
resources, because that's how DeltaV works. You don't much like the
idea of being able to poke at where the repository starts because you
want everyone to think about the individual resource and not the
container it lives in. But that's not really the Subversion model; in
Subversion, the container *is* the versioned resource, and the
individual file or directory is just a piece of it. It makes perfect
sense to want to know where the versioned resource starts in that model,
even if the core Subversion operations don't generally need to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org