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.
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
(Yes, there's a reference to the moment file has been Copied, but that's only
made for reference, to give investigator an idea of what could've been done to
the file, and where to look. As you can see, the file was merGed back to the
trunk in my example, but no mention if it was edited in between 59 and 77 -
you'd have to run another track for that file in branch to discover that)
> That is, a path and revision in peg revision form uniquely identifies an
> object, and that object has a certain amount of history.
> However that same path at any other revision may be an entirely different
> object with a different history or may not exist at all. If subversion
> starts to track the 'copy-to' info so you can follow revisions in the
> forward direction, you can end up with many different descendants with
> different paths, but it's not clear that would make it any easier to find
> the dead ends of deletions.
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.
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.
> 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.
> Also, when you copy a directory in subversion, you expect it to bring
> along all of the history of that directory and the objects under it. If
> you want it to remember that a deleted object once lived under a certain
> path, when that path is copied, would you also want it to think that the
> deleted object was once under this new copied path?
You asking a question that has no meaning. Subversion copy copies current
state. Deleted files do not present in it.
I don't see any problem. Or clarify your question. (provide use-case?)
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 30.11.2010, <21:22>
Sorry for my terrible english...
