Gerco Ballintijn wrote:
> C. Michael Pilato wrote:
>> Gerco Ballintijn wrote:
>>> Hi,
>>>
>>> I stumbled across the following, condensed in the attached script.
>>> The scripts does the following:
>>>
>>> r0: create repo
>>> r1: create directory /test (directly in repo)
>>> r2: create file /test/f1 (via a commit)
>>> r3: create /other1 (directly in repo)
>>> r4: rename /test/f1 to /test/f2 (via a commit)
>>> r5: create /other2 (directly in repo)
>>> r6: rename /test/f2 to /test/f3 (via a commit)
>>>
>>>
>>> So, the same file object is called f1 in r2 and r3, f2 in r4 and r5,
>>> and f3 in r6. Now I assumed (as in the script) that "svn info -rX f3"
>>> would give me info (for 2 <= X <= 6). However, for r3 and r5, it gives
>>> the error "Unable to find repository location". Isn't this a bug, or
>>> am I missing something fundamental?
>>
>> I betcha if you run 'svn log test/f3', you'll see that your two
>> renames have
>> copy-from revisions that aren't REV-1, but REV-2. For example, the
>> log for
>> revision 6 will show
>>
>> A /test/f3 (from /test/f2:4)
>>
>> *not*
>>
>> A /test/f3 (from /test/f2:5)
>>
>> This is likely because you forgot to update your working copy before
>> committing the renames.
>>
>
> Given that, as indicated by Malcolm Rowe, performing an update isn't a
> solution, renames can always result in these "gaps" in the file history
> where a file seems to disappeared and appear again (but not when you
> perform a checkout). Do you really consider the current handling of
> these "gaps" acceptable? desirable?
Actually, the more I thought about the situation, the less I felt like I
understood what you were seeing. I don't think my explanation gels with you
seeing things that seem to "disappear" -- there really shouldn't be any gaps.
Any chance you can provide a shell script to reproduce exactly what you're
seeing?
I've been concerned for some time that there might be a bug in our
repos_get_locations() code (based on a weird bug report I've been trying to
field over in the ViewVC project). So a good repro recipe from you could be
key to this research.
Thanks (in advance).
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Apr 5 05:44:51 2007