On Thu, 2011-03-10 at 20:06 +0100, Bert Huijben wrote:
>
> > -----Original Message-----
> > From: Julian Foad [mailto:julian.foad_at_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
>
Received on 2011-03-10 20:18:23 CET