On Mon, Mar 8, 2010 at 14:42, C. Michael Pilato <cmpil...@collab.net> wrote: > Greg Stein wrote: >... >> In the old way of doing thigns, if the schedule was >> svn_wc_schedule_replace, then wc_db is going to return >> svn_wc__db_status_added for that condition. There are other >> considerations for determining "was this a schedule_replace of a plain >> schedule_add?" >> >> I've gotta run to a lunch. But if you look at >> questions.c::internal_is_replaced(), then you'll see that determining >> schedule_replace is a difficult problem. And the original >> schedule!=add condition *may* be looking for schedule_replace. >> >> But that is maybe the trick here, and why your testing did not find >> the code. Maybe it is only possible to see >> schedule_(normal|add|delete), and never a replace? That may narrow the >> amount of querying needed against wc_db. I can't take a look right >> now, but the comments suggest there may be very restricted conditions >> here. > > My attempts to get a mental handle on this situation have led me to more > questions. (Big surprise, right?) > > In the 1.6.x code, mark_tree() (which has become mark_tree_deleted()) did a > similar iteration over children -- skipping the "this dir" entry -- before > acting on the directory itself. To what degree does the "this dir" paradigm > continue to invade WC-NG? Obviously once we have a single DB per working > copy, there will be no more need to distinguish between "this dir" in > some/dir/.svn/entries and "dir" in some/.svn/entries. But until then?
For the most part, we don't worry much about "this dir". The wc_db conceptually has just one block of metadata associated with "/some/path/to/dir". Implementation-wise, however, we *do* still have two blocks of metadata. Thus, we have some internal goings-on to deal with that, and a few temporary APIs like db_temp_is_dir_deleted(). The differences *do* come up when you are messing around with access batons, since those define the reference point. But as we eliminate the batons, we also remove the need to distinguish *which* reference point you're using. > I *think* mark_tree_deleted() is effectively doing the same thing -- it > iterates over children, but while it doesn't explicitly have code to skip a > "this dir" entry, my reading of db_read_children() leads me to believe that > it never returns that kind of fake entry anyway. In other words, > db_read_children() appears to be ready for the single-db lifestyle. Is that > accurate? db_read_children() only returns children (per the name!), and never "." Cheers, -g
