On 11/30/2010 12:58 PM, Andrey Repin wrote:
> Greetings, Les Mikesell!
>
>>>>> Still, this should at least produce some results: (as long as foo existed
>>>>> in rev 3)
>>>>> svn log -r 0:head file://${HOME}/trash/repo/foo_at_3
>>>>> svn: File not found: revision 5, path '/foo'
>>>>> It makes no sense for svn to complain about what's in rev 5. My query
>>>>> doesn't care about rev 5.
>>>
>>>> I think the principle was covered in another response, but the only way
>>>> you can get history is to start from the highest rev and follow
>>>> backwards, and you are asking it to start from head, which is impossible.
>>>
>>> Impossible within current realization of storage backend. But sensible from
>>> user's viewpoint and scheduled to be resolved in future.
>>> I'd ask you to stop giving out your own opinion under mask of absolute truth.
>
>> I'm admittedly not an expert, but I don't understand exactly how this
>> can be resolved to work the way you want when the names of objects are
>> only loosely connected to the objects themselves.
>
> This is not a problem at all.
> The simplest solution I can imagine is to maintain a table
> revision|URL|action|previous_revision|previous_URL
>
> Walking this table back and forth is as quick as any usual database operation.
What database operation is fast when it has to follow recursive
self-references in the same table? Each time you copy a high level
directory (typical for users that tag frequently) you'd have to have an
entry for every path below it. When you follow forward, you'll explode
out a tree of new paths.
> And some new command could be added to svn program to give result similar to
> status command, but including revision numbers.
> Something like
> A 5 /trunk/frontend/fig1.php
> MM 7 /trunk/frontend/fig1.php
> M 8 /trunk/frontend/fig1.php
> D 26 /trunk/frontend/fig1.php
> A 57 /trunk/frontend/f-o.php
> R 58 /trunk/frontend/fig1.php
> C 59 /branch/xxx/frontend/fig1.php
> GM 77 /trunk/frontend/fig1.php
And how should this look if every operation is a move/rename? Or copies
followed by different renames out each branch?
> If it start to branch, each of these files will have it's own tracking onward
> from the branching point. Nothing wrong with it. Or do you concerned with
> tracking request output? It's not a problem either. As long as URL wasn't
> renamed/deleted, it should keep giving out the mainline.
But that's the point. Things are copied and moved regularly. And
renamed temporarily and then back.
> You're right that URL_at_PEG form an unique identity, but making a mistake
> thinking about URL across whole range of history. As you pointed out, URL
> alone isn't enough to identify the file. But that's not a problem, because
> Subversion wouldn't be working over whole repository, only with each revision
> it know of, sequentially.
There's only one way back through history but no limit to future
branches if you want it to look forward.
>> I can see that subversion could, with some extra work on the server
>> side, track down the end of the line in the future of foo_at_3 by examining
>> every subsequent revision when you ask for:
>> svn log -r 0:head file://${HOME}/trash/repo/foo_at_3
>> But what should it do if a different object with the same name but a
>> different history has been copied into head where you are really asking
>> it to start giving history?
>
> If it'd be implemented right, Subversion would not see these files at all.
> It'd simply NOT look into HEAD in first place.
It only looks in head because that command asks it for the history of
head. If you are asking it to follow the object forward for as long as
it existed in that path the server could probably figure that out with
some brute force although even there things would be messy if you
renamed it, then renamed it back some revisions later. Or maybe made
many copies, one of which was eventually copied back.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-30 21:22:40 CET