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