Greg Stein <gstein@lyra.org> writes:
> I don't see anything about adding a revision to delete_entry() in any of the
> three issues that I'm looked at.
>
> Adding it doesn't bother me... but what *does* bother me is that we ruled
> against it once before for *some* reason. Why? What are we forgetting?
I had to follow the mailing list archive reference mentioned in the
first comment in issue #463.
The basic summary is: we didn't have it before because we didn't need
it -- if you were deleting an object from a directory, you could get
the relevant revision from the directory baton. But the new commit
system is the final step in disconnecting directory revisions from
what is versioned inside the directory. In the mail archives, I found
this rough description of the new algorithm, which should make it
clear why `delete_entry' needs to take a revision argument now:
> There's another way to do things, fortunately. We have a magic "back
> door" to get what we need, without *ever* fetching that old directory
> listing. Every node remembers what revision it was created
> (committed) in. So we have these pieces of data:
>
> 1. The file's revision number on the client side.
>
> 2. A node revision for it in the repository head, cheaply
> obtainable because the head is fulltext, or still very near
> fulltext by the time you get a handle on it anyway.
>
> 3. The revision number in which the head revision of the file was
> created, via point (2).
>
> Thus we can use this new commit algorithm on the server-side, whose
> big advantage strength is that it avoids undeltifying numerous parent
> directories just to discover an old node-rev-id:
>
> 1. First of all, ra_local should base transaction on the youngest
> revision Y, as ra_dav does, not the revision of the working
> copy parent. This makes for cheaper merges and some more
> convenient code paths, although it doesn't directly solve this
> bug or anything.
>
> 2. For each committed target TGT at revision N that we receive:
>
> - Get the node-rev-id of TGT at revision Y. This is a
> fulltext retrieval, therefore cheap.
>
> - Look inside this node-rev-id, it will tell you what
> revision it was committed in. Call that revision L.
>
> - if (N < L)
>
> Then TGT at revision N is obviously out-of-date, because
> somebody changed it in revision L. Signal a conflict
> and bail early. Note that you never looked at the node
> ids themselves.
>
> else if (L <= N <= Y)
>
> Everything is fine; TGT at revision N is up-to-date,
> because we know that nobody has changed the node-rev-id
> between revisions L and Y. Drop Y's idea of TGT's
> node-rev-id into the transaction, and await a
> text-delta.
>
> else if (N > Y)
>
> A very rare situation, though possible if you really
> work at it (we know a scenario, but it's one that will
> "never" happen). Anyway, just bounce back with an
> out-of-date error, or else re-base the txn on the new
> youngest revision and redo the changes.
>
> That's the basic idea, though I've hand-waved on a few details --
> handling for added and deleted files, for example, plus you can see
> that some of the checks can be a bit fancier, and by remembering the
> node-rev we can do a predecessor/successor check as well, blah blah
> blah. [...]
None of the checks that compare `N' with `L' can work unless
`delete_entry' takes a revision argument independent from its parent
directory.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006