On Thu, 2011-03-10 at 20:06 +0100, Bert Huijben wrote: > > > -----Original Message----- > > From: Julian Foad [mailto:julian.f...@wandisco.com] > > Sent: donderdag 10 maart 2011 19:43 > > To: Subversion Development > > Subject: [RFC] Children of a replaced node - schedule delete vs. deleted-by- > > the-replace > > > > If I ask a WC API for "the children" of a working directory, I would > > expect to get just the children that belong to it, not including any > > paths that were children of an underlying directory that has been > > locally replaced. > > > > The attached patch starts this by creating a test and defining a new > > version of one of the APIs. (Only the API description is different, the > > signature is the same.) > > > > Sanity checks appreciated, especially of the test. I'll describe the > > test. > > > > I start with a repo and clean WC at revision 1 containing just the > > following directories (no files): > > > > A > > A/F > > A/G > > A/H > > X > > X/G > > X/H > > X/I > > > > and then (in Subversion) I replace A with a copy of X: > > > > rm A > > cp X A > > > > and then delete the child 'H' and add a new child 'J': > > > > rm A/G > > mkdir A/J > > > > I expect to the "working view" of A to consist of > > > > A - copied, replacing an old 'A' > > A/G - scheduled for delete (was a copied child of 'A') > > A/H - copied (as a child of 'A') > > A/I - copied (as a child of 'A') > > A/J - scheduled for add > > > > Note that I don't expect to hear anything about the path 'A/F'. > > Currently, 'F' is included in the results returned by > > svn_wc__db_read_children() and svn_wc__db_read_children_info(). > > > > On the right track? > > For the new api's that might be nice, but in the old entries world we > expected to see through all the layers.... there were no layers.
I need this definition to use in harvest_committables() to make it look at only the relevant children and thus fix the delete-inside-replacement bug. I assume it will be useful in other places because it just makes sense at a high level. We can leave the old "see-through" API in place for backward compat behaviours. - Julian p.s. There was an error in the (hand-tweaked) SQLite dump I attached: the second-last line should have had relpath 'A/G' not 'A/H'. > So if we remove them now we have to somehow show them in all the > deprecated wrappers. In our test suite we assume svn status shows > these deleted nodes, so even there we would have to show them via some > alternative route if we remove them from the normal children. > > So I think this would be nice for 2.0+, and a lot of work everywhere > if we do it now :( > (For AnkhSVN I'm afraid that I would have to bring them back in too, > to make sure I see all project definition changes) > > Bert >
