On Nov 18, 2009, at 2:57 AM, Philip Martin wrote: > "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > >> On Nov 17, 2009, at 10:18 AM, Philip Martin wrote: >> When you refer to "the database" are you talking about the sqlite >> database or the wc_db? Only code within wc_db.c knows about the >> sqlite database (with certain exceptions for upgrading to wc-ng). >> libsvn_wc code external to that file should just use the similarly >> opaque wc_db handle to do whatever actions it needs to. > > I was refering to the database associated with the working copy, I > wasn't making any assumption about how it was implemented. > > There is a bit of a problem with the client not knowing about the > database as it makes svn:externals a bit tricky. Consider the path > "/path/to/wc/foo" where "foo" is an external of "wc". How does the > function > SVN_ERR(svn_wc_foo(wc_ctx, "/path/to/wc/foo", ...)); > treat "foo", does it treat it as an external of "wc" or as the root of > "foo"? In the old code the client could choose to open either "wc" or > "foo" and that determined how foo got treated.
This is actually a more general problem than just externals. For instance, directories have two entries, one in the parent (the "stub") and a full entry in the directory itself. For cases where it currently matters (fetching entries, for instance) we have a need_parent_stub parameter in which allows the caller to specify whether to act on the stub entry in the parent or on the "real" entry in the directory. Such a paradigm is confusing and fraught with opportunities for error, and one of the benefits of moving to wc-ng means that all the information required for a given location in the filesystem is indexed using a single location in wc_db. The needs_parent_stub parameters will eventually disappear. -Hyrum
