Stefan Küng wrote:
> When I specify
> svn cat ^/file3.txt_at_4 -r3
> that means I like the content of the file named file3.txt as it was
> located in r4, but as it looked in r3. I think that's what a peg
> revision is for: I want to look at a path in an earlier revision where I
> have no idea what location it has in that revision, so I give the peg
> revision for the path I know in that revision.
Yes. PATH_at_PEG-REV must be a known location of the object of interest, and
then you add -rWORKING-REV to get the revision of that thing you care about
without needing to know what path the object lived at in that revision.
> since ^/file3.txt_at_4 existed in r3 (it was named file.txt in r3), I think
> that command has to work.
The command doesn't work because Subversion's repository doesn't support
forward history searching. When you identify the "line of history" you care
about (using ^/file3.txt_at_4 as the input), Subversion can walk backwards
toward the origin of that object (in r1). But it can't walk forward. (You
know this already.) So the last known location of the file in question is
file.txt_at_2. You've asked about r3, and the code shrugs.
I have this memory of the code trying something clever, like, if you did
'svn cat ^/file3.txt_at_4 -rHEAD', it would look for ^/file3.txt_at_HEAD and at
least make sure that it was related to ^/file3.txt_at_4. And maybe it only did
that because HEAD is younger than the peg revision. I suppose we could
apply similar logic to any working rev that doesn't get an obvious "hit" in
the ancestry search (by making sure that PATH_at_WORKING-REV is related to
PATH_at_YOUNGEST-REV-LOCATED-VIA-PEGREV-STILL-OLDER-THAN-WORKING-REV. Or somesuch.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-06-15 20:44:22 CEST