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/f...@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?
SELECT operation, even on a multitude of arguments, is relatively fast.
Hell, even UNION JOIN over a NetFlow data is just about a few seconds.
> 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.
Not a problem, really. This is strictly server-side operation, means it is
done on a fast backend, not affected by network issues. Doubt it could be
slower than real-time walking on a graph with 6k points.
>> 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?
I specifically mentioned this moment it in the part you striped from quote.
>> 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.
Nota a concern. Mainline go on and at some point die (if at all), giving all
sort of hints, as to where to look further, in process.
If you REALLY want to see if the file was moved back instead of merging, you'd
run a new trace from one of the branching points.
>> You're right that u...@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.
There CURRENTLY only one way - back. This is a deficiency of current backend
realization. And amount of future branches is not a problem at all, if you
stop banging your head over it.
>>> 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 f...@3 by examining
>>> every subsequent revision when you ask for:
>>> svn log -r 0:head file://${HOME}/trash/repo/f...@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.
No.
Really, I see this as pointless discussion. You absolutely don't hear my
arguments.
P.S.
Please don't use "reply to all" in reply to my posts. It's not a big problem
deleting a few more messages from my inbox, still it's disturbing.
TIA.
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 01.12.2010, <14:07>
Sorry for my terrible english...
