Philip Martin <philip@codematters.co.uk> writes:
> I didn't look at Brian's repos code in detail, so I can't comment on
> that, my question is about svn_ra_reporter_t.delete_path. This is the
> function that the client calls to describe a working copy path as
> missing. Obviously the client must know about the path to be able to
> call delete_path, it strikes me as odd that in this case the client
> doesn't get any response from the repository. In the normal case (no
> repository delete) the repository responds to the delete_path call,
> why should the delete case be different? It's possible I don't
> understand the intention behind delete_path.
Keep in mind that the reporter interface exists for no other reason
than to build a filesystem transaction that mimics the state of the
working copy. We build this exact duplicate of the working copy base
as a filesystem transaction so that, when diffed against a pristine
revision tree (the revision to which we are updating), that diff
represents how we need to change our working to make it look like that
revision.
Reporter->delete_path() is meant only to only to inform that
repository that the client is missing something that appears to exist
as a child of its parent in the revision of the parent that the client
currently has. Entries marked 'deleted' fit this criteria (because
this state represents the very definition of what it means to be
'deleted'), and missing directories fit the criteria. We've always
been calling delete_path for missing directories -- that won't change.
But it's also (obviously) not enough to solve the problem. In the
recipe, the working copy is missing something that has also been
deleted in the repository since the last time the client updated. Of
course, the client doesn't know this. It just knows that it's missing
something. So, when updating, the client builds this transaction that
looks like the working copy, calling reporter->delete_path() on the
missing item. Now there is a transaction with absolutely no reference
to this missing thing. That is diffed against a pristine revision
which, again, has absolutely no reference to that missing path,
because in that revision, that path no longer exists. Obviously, if
you diff two trees that are both missing the same thing, there is no
diff output regarding that thing.
In the normal case you cite, the repository responds to the
reporter->delete_path() call in the same way as usual, by removing the
path from the temporary transaction before doing the tree delta. The
difference is that typically the path still exists in the pristine
update revision, so there actually *is* delta output, specifically
output that says "the revision has this path, you don't -- so you need
to add this path".
> > I dunno how that it would all turn out. I still think the fix should
> > be client side.
>
> I agree it could be solved there, but solving it on the client side
> means that every client has to be aware of the problem and has to find
> a solution.
Well, yes, but that's why we have a librarized implementation. These
changes all live in libsvn_wc -- I dunno anybody crazy enough to write
their own libsvn_wc library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 6 16:47:38 2003