[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 00:43:34 CEST

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?

With regards,
Gerco Ballintijn.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 5 00:43:49 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.