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=1354336
Received on 2009-03-19 10:16:30 CET