Hyrum K. Wright wrote:
> 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().
> I'm not sure what the Grand Plan for wcprops in wc-ng is.
> Unfortunately, we 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'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?
Not sure if this helps you to decide or not, but the current WC
implementation has two different property stores, one for regular versioned
properties (which has both BASE and WORKING), one for wcprops (which has ...
neither, really). The wc-props abstraction isn't strictly required going
forward, but when talking to pre-HTTP-v2 servers, the absence of wc-props
has the potential to vastly slow things down.
(There's a third concept called "entry props", but these find their storage
as fields in the svn_wc_entry_t.)
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2009-03-19 06:19:40 CET