On 11/30/10 5:21 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.
But the name has nothing to do with the versioning of the object. Names appear
in the directory containing it. The object itself might have a different name
every revision if the modifications are moves. Or the same name might be a
different object with deletes followed by adds or copies to the name in
question. Subversion only tracks the object itself using the name to identify a
starting point. But you can see the names come and go in the history of the
directories containing them.
>>> 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.
> 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.
You have that in the versioning of the directory where the name appears.
>> 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.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-30 14:51:35 CET