The problem is with r36663. I backdated to 36662 and the test passed.
Failed with 36663. Hellifiknow *why* though.
Gonna investigate around this revision. Weirdness...
On Thu, Mar 19, 2009 at 10:16, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Mar 19, 2009 at 05:30, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> Greg,
>> It appears that the currently failing tests on trunk over ra_neon are due to
>> various issues running the wcprops log. It's the same set of tests which
>> fails when do_sync is removed from svn_wc__entry_modify(), and I think it
>> has to do with the fact that read_entries() now returns a unique hash from
>> prune_deleted().
>
> Not entirely surprised :-(
>
>> I'm not sure what the Grand Plan for wcprops in wc-ng is. Unfortunately, we
>
> My initial thought was to lump them in with the other properties at
> the wc_db level. libsvn_wc can sort them out on its own (we have
> functions to classify any given property name).
>
>> still need to store them for compat reasons with the older http protocol.
>> Are they just part of the properties hash in BASE, or should there be
>> another column for wcprops? (Thankfully, unlike "real" properties, wcprops
>> only have a BASE version, not WORKING or ACTUAL.)
>
> I believe there are WORKING wcprops, too. Or if we don't have the
> concept in wc-1.0, then we *should* in wc-ng. Consider copying a
> subtree down from the repository. We may want to cache the version
> resource URL (I say "may" because I'm not positive without more
> thinking about when/where wcprops are truly used).
>
> If the wcprops are just lumped into the other properties in wc_db,
> then this poses no additional difficulty.
>
>> I'd like to get these wcprops issues ironed our fairly quickly. I think
>> that we can implement simple wc-ng prop handling for wcprops, switch over to
>> that, and fix the test failures on trunk. This should be relatively
>> straight-forward *and* give us some context for use in props.c. Thoughts?
>
> I'd suggest going with the "lump in with others, and sort them at a
> higher level" approach. See how that goes. Does that seem reasonable
> to you? Alternatives/suggestions?
>
> Cheers,
> -g
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1360400
Received on 2009-03-20 03:41:05 CET