I wrote:
> (1) I *think* that the editor could "do the right thing" by
> always generating a delta when the source directory is missing --
> i.e., if the directory is present in the target, do an
> add (restore), and if it's absent in the target, do a delete. But
> that would also require some way of signaling a missing path to the
> reporter as distinct from a deleted path (not to mention that i have
> no idea how the missing item should be represented in the transaction
> "source tree").
and later, Ben Collins-Sussman wrote:
>
> Perhaps schedule-delete directories shouldn't be described as missing
> at all -- only "deleted" ones. That would make the server send a
> deletion command, which the client would then carry out, even in the
> presence of a schedule-delete: it could be considered a case of
> "merging" tree changes from the server which don't conflict.
[light bulb goes on in brian's head]
oh, your suggestion is in the context of the idea i posted above, yeah?
so the server will always give out the delta if the source directory is
missing, and your suggestion is that the way we tell it's missing is that
if it weren't missing we wouldn't have called reporter->delete_path (?)
interesting.
if i'm understanding you correctly:
Presence/Absence of dir in txn trees
State Source tree Target tree Action
1. absent/missing present add
2. missing absent (current: nothing;
proposed: delete)
3. present absent delete
4. present present [not relevant here]
Cases which result in state 1:
- wc dir missing; exists in target rev
- wc dir DNE; exists in target rev
Cases which result in state 2:
- wc dir missing; deleted in target rev
- [sussman suggests that this state should *not* result from a wc dir that
is scheduled for delete]
- [note that for this to work, the update editor must still be able to
differentiate a source dir that is absent because we called
reporter->delete_path (or something else) from one that is simply
nonexistent; at least, there must be *something* for the editor to
iterate over. i haven't looked at the FS/txn code enough to know
whether there's a mechanism in place to make this distinction for us.]
Cases which result in state 3:
- wc dir exists; deleted in target rev
- wc dir scheduled for deletion (per sussman's suggestion); deleted in
target rev.
... is this what you had in mind? further comments?
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 21 21:11:06 2003