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 Hudson <gh...@MIT.EDU> on 2002/05/30 00:34:43 UTC
Re: repository URLs (was: Just say no to collections: moving wc
meta-data out of the wc)
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
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