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/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? 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 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.
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. 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
lesmikes...@gmail.com
