Re: RFC: a permanent svn-specific URL syntax

On Wednesday, June 4, 2003, at 04:08 PM, John Locke wrote:

>> What you're actually asking the repository for is a revision of the
>> tree, and then a particular resource within that tree (i.e. the
>> tree is the *first* thing to be found, from the revision number).
>> Going to the resource first, then moving backwards, is, well,
>> backwards.
>>
> I see your point, but this is an implementation detail.

No, it isn't an implementation detail, it is a storage model detail.
It doesn't matter if it is implemented in paper cards on a pile on the
floor, the revision choice is made first (see below for an example).

> Seems to me that
> if you actually want to see an earlier version of a file, then you
> ought
> to be able to put together a simple URL with a query string to do it.

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)?

> I still don't see why this is a bad thing.

It isn't a bad thing per se, but it isn't what people have been
discussing. They've been discussing queries of type ii). Your
suggestion is quite good for queries of type i).

I should also say that I'm not sure subversion should have this
functionality (either type) at all. Once we support one of these types
of queries, there will be a call to support the other, then to...

For an example of where these two types of query differ:

mkdir testsvn
cd testsvn
svnadmin create repos
svn co file://`pwd`/repos trunk
cd trunk
echo "FileA" > file1
echo "FileB" > file2
svn add file1 file2
svn commit -m "added file1 and file2"
svn rm file1
svn commit -m "removed file1"
svn mv file2 file1
svn commit -m "moved file2 to file1"

Now, when look at the contents of file1 at revision 1, what do you
expect to see? "FileA", or "FileB"?

Your syntax would suggest to me you expected to see "FileB" - If you
take file1 and follow its history back to revision 1, it contains the
text "FileB". (This is easy to see: it contains the same text in all
revisions as the text never changes.)

Other people are talking about finding a way to view the text "FileA".
Note that there is NO file in head that corresponds to the file we want
to look at - it has been removed. We need a type ii) query as no type
i) query will give us what we want. This is why people have been
talking about type ii) queries - they allow access to everything,
whereas type i) queries do not.

With a type ii) query, the revision changes the meaning of the path.
For this reason people are arguing that it should come first in the
URL. (As I said above, I wouldn't put either in, but I don't really
care - I'm not going to be maintaining it.)

Cheers,

Will :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org