> -----Original Message-----
> From: Les Mikesell
> On 11/29/2010 11:45 AM, Ludwig, Michael wrote:
> > I can see that from the peg rev point of view, HEAD is the
> > future. But I think we can also agree that from the SVN user's
> > perspective, every single existing rev including HEAD is in
> > the past.
>
> Yes, but from the perspective of getting history where you can
> only go backwards, you have to specify the right starting point,
> and a rev where the thing doesn't exist isn't the right place.
Certainly. Just imagine you weren't required to specify a revision:
svn show svn://server.dev/eins/zwei/drei/vier.txt
seq node-id revision status
1 1bca349 33 A
1 1bca349 75 M
1 1bca349 76 M
1 1bca349 111 M
1 1bca349 188 D
2 4941b20 1099 A
2 4941b20 1101 M
2 4941b20 1108 M
2 4941b20 1831 D
3 6e6cdff 18004 A
3 6e6cdff 18014 M
The node ID would identify the versioned object. (I don't know
anything about what the node ID might look like; the example is
just a wild guess.) This sketch certainly has flaws, but is it an
unreasonable proposal? Users might find it useful.
> > Yes, there could be several items - several revision ranges -
> > in the index, pointing to several unrelated objects. But is it
> > a big problem?
>
> Yes, if you are in the habit of deleting things and adding them
> back, then wanting one of the deleted versions.
You'd read it from the list and identify it by revision. No
changes to existing behaviour and functionality.
> > In database speak, we'd indeed have a compound key for
> > *uniquely* identifying an object, with the first part of that
> > compound key being the URL, and the second part the revision.
> > But if we don't know the revision, we simply use the URL alone
> > and receive a list of all the items ever to have appeared at
> > that URL. Which ones we're interested in is then a matter of
> > human decision; but gone is the tedium (or wasteful scanning)
> > of establishing the list in the first place.
>
> That's a reasonable thing to want, but perhaps not reasonable
> for the server to deliver. Would you expect your database to
> find things for you if you renamed or deleted the table holding
> them?
I wouldn't. But if I had a trigger to log changes made to a table
to a log table I'd expect the system to know the table history.
That's maybe a bit more aligned with what I might expect from a
version control system.
> >> A thing with the same name added later as a replacement may
> >> have nothing in common with the item you want. I'm not sure
> >> what the right test for this would be other than asking for a
> >> log with a rev range and a peg rev to anchor it to one
> >> specific version.
> >
> > Give me a listing of the things and either require me to
> > specify which one I want or show them all in full detail,
> > depending on the circumstances. In the special case where
> > there is only one item in the list, no further precision is
> > needed.
>
> It's a big order to make that happen through a client-server
> connection that has no such existing concept and no server side
> hints to do it efficiently.
I agree the server side needs to have the URL index to do it
efficiently. Given that index, however, it shouldn't be difficult.
I wouldn't redesign the existing set of commands, just provide
one in addition that provides the history of a URL.
Best,
Michael
Received on 2010-11-30 12:21:53 CET