[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is this a peg revision bug?

From: Gerco Ballintijn <gerco_at_ballintijn.com>
Date: 2007-04-05 11:21:50 CEST


On Thu, April 5, 2007 05:44, C. Michael Pilato wrote:
> Gerco Ballintijn wrote:
>> C. Michael Pilato wrote:
>>> Gerco Ballintijn wrote:
>>>> 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.

You're explaination was correct, the copy-from revision was r4 not r5
(and r2 not r3). So, the fact that the file wasn't found by the back-
tracing peg-resolution algorithm is explainable, and my "problem" doesn't
appear to be a programming error. It is, however, counter-intuitive when
the peg algorithm algorithm claims it cannot find a file in revision X
and that "same" appears when checking out revision X.

> 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.

See attachment, but I don't think they are related.

With regards,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 5 11:22:06 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.