On Wed, 2004-03-10 at 13:17, Greg Hudson wrote:
> On Wed, 2004-03-10 at 13:06, Greg Hudson wrote:
> > Fascinating. Yes, it should fix something. I'm surprised the world
> > doesn't come crashing down as a result of this bug, actually
>
> Okay, I figured out why: in this particular case, the value of s_entry
> is actually never used, because there's always some report information
> which takes precedence.
See Greg. See Greg vacillate.
There's a somewhat unusual corner case where what I said isn't true.
Say you have a working dir with the top level at rev 1, with foo at rev
1, and with foo/bar at rev 2. The report will involve a
set_path("foo/bar", 2). In this case, in the loop in question,
fetch_path_info() will return "foo" with info set to NULL, which means
"I have no overriding report information for foo, but I do for a child
of foo". In this case, s_entry is not overridden, so we can't just pass
NULL, and passing the wrong value as we currently do could cause
problems. But it is not surprising that the test suite does not cover
this case.
So, Julian, please go ahead and commit your patch. Sorry for the
confusion.
Reproduction recipe, in case anyone wants to make a test case:
<create an empty repos, check it out, and cd into the wc>
svn mkdir dir
svn mkdir dir/subdir # Could be a file, doesn't matter
svn ci -m logmsg
svn rm dir
svn ci -m logmsg
svn up -r1
svn up -r2 dir/subdir
svn up
With the current code, you get the error:
svn: Working copy path 'dir' does not exist in repository
With Julian's patch, the final update works fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 10 19:33:11 2004