> -----Original Message----- > From: Les Mikesell > On 11/30/10 5:21 AM, Ludwig, Michael wrote: > > > > 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. > > But the name has nothing to do with the versioning of the > object.
True, but many humans tend to attach meaning to names, to remember them, and to refer to them. For example, names often appear in the contents of other files. They just have a tendency of cropping up here and there. People might find it useful if Subversion had better support for this. > >>> 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. > > Where does the client/server protocol have such functionality > now? I think it is only in showing a log -v of the directory > containing the name. It doesn't have this functionality right now. You'd have to parse the output of "log -v", yes. It's onerous on both the server and the human. > >> 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. > > That already exists. A 'log -v' from the top of the repo will > show all deletes and adds ever done. The output isn't > convenient to feed to grep, etc., though. It would work, somehow. I'm aware of that. I'm just imagining a more convenient feature that also performs better. A lookup instead of a scan. Michael
