William,
Thanks for putting the difference in clear language. I appreciate
everyone taking the time to educate me on this...
On Wed, 2003-06-04 at 03:53, William Uther wrote:
> There are two different things you can ask for:
>
> i) What the file in HEAD called 'blah' looked like in revision X.
> ii) What the file in revision X called 'blah' looks like.
>
> These are very different things. If svn were to include viewcvs, then
> it would need to display both. It is not clear to me which of these
> you think svn should display.
>
> > When you view a directory, it also seems to me that it shouldn't be
> > difficult to append the query string to each of the links in the
> > directory, so you can browse the revision to see all the files.
>
> So you want a query of type i)?
>
Actually, I haven't extensively played around with svn mv, but I would
expect the behavior of type ii).
As the book says about svn switch, we have two dimensions to work with:
time and space. So what I would expect is that the query string
specifies the time, and the path specifies the space.
If a file exists at whatever time (revision) specified in the query
string, then I would expect to get the file at that revision with the
specified name--not the version of the file with that name in the HEAD
branch at the specified revision.
I guess where I seem to be differing from everyone else is that I see
the query string as completely independent of the path.
What I would expect out of this is exactly the behavior of svn
update--if there's a revision specified, get the file at the revision
with the name you specified. If there's no revision specified, get the
HEAD revision. If the file doesn't exist in a particular revision,
return 404. If a directory was specified, show the contents a la svn ls.
In fact, the more I think about it, the more I don't see the need for
type I) in a web interface at all--that's what the log is for, to tell
you how the file has changed over time. What I want to be able to do is
just get whatever is there at the specified time (revision).
I can't imagine this would be hard to implement--hooking the update code
to the web client. I've built web sites that pass a couple dimensions of
an array in the path, and still pass a query string that can completely
change what is returned in the page.
Again, I'm coming at this from a user point of view--I have a need to
retrieve earlier versions of a file from my repository from machines
without Subversion installed (at a client site, for example). I also
have a need to segment my repository so that I can provide such a URL to
a client and not give them access to other client's files, which is what
I currently can't do without creating entirely separate repositories.
Which is why a URL schema would be great.
The biggest reason I want the TIME component to come after the SPACE
component in the URL, is because that's how I want to segment
access/authorization to the repository. I can't think of a reason I
would need to block access to individual revisions of a file--I could
just add a copy somewhere else if I really had that need. But there's
plenty of reasons I want to protect branches, tags, and whole sections
of the repository, and I see a consistent URL scheme as being the
easiest way to do this.
Cheers,
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 4 17:17:14 2003