Ben Collins-Sussman wrote:
>
> No, it's definitely supposed to be comparing the two values. assert()
> always tests a condition. Putting an assignment into assert(),
> especially when the right-side of the assignment is a positive
> integer, will always return a "true" value. So it's a meaningless
> assertion now. The change you made is equivalent to having written
> assert(1), which will always succeed. You might as well have deleted
> the whole assert call. :-)
>
> So the question is: *why* does the code expect repos_text_status to
> be svn_wc_status_added? And how does it happen that this isn't true?
>
Beats me.
Okay. I just figured out steps to reproduce, and determined the
situation. There was one file in the problem directory that was
"updated" to an earlier version. This causes the bug. I worked around it
by doing the right thing--copying the desired version to a new branch,
and switching the file to the branch. But it's quite an unfriendly
response...
Steps:
1. Check out a working copy from an existing repository with lots of
revisions and subdirectories.
2. Use svn up to get an older copy of any file in one of the subdirectories:
svn up -r PREV subdirectory/file.txt
3. Now, in the parent directory, try to do a non-recursive status on the
directory:
svn st -uvN subdirectory
You'll get the error.
Cheers,
--
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 27 22:29:56 2005