On Fri, Apr 25, 2003 at 08:37:41AM -0500, cmpilato@collab.net wrote:
>
> Well, this error occurs when two `change' items appears in the same
> transaction and for the same path, but using different NODE-REV-IDs,
> and without an intermediate `delete' change.
>
> I could explain that if you want, or perhaps you could explain your
> plan of action for fixing issue #1075. I was surprised to see that
> the fix for issue #1075 involved *any* server-side changes.
I'd love it if you'd explain further... but i'll explain my plan of
action now.
First, you should review the thread at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=246816
so i don't have to repeat it here. In the first post to that thread,
I gave two ideas for fixing #1075.
Philip was concerned about idea (2), and Ben had ideas about (1), so i
decided (1) was the way to go if it seemed reasonably doable. (let me
know if you disagree).
the crux of idea (1) was, if a path in the source txn was "missing",
then the editor should always generate a delta -- delete it if it's
absent in the target tree, add/restore it if it's present. The
add/restore case already works; my job is to fix the delete case.
the basic difficulty with implementing this idea is: how do you tell that
a path in the source transaction was missing, as opposed to simply absent?
(this has to be distinguished, AFAICT, for reasons explained in the
quoted thread). Ben pointed out that you don't have to call
"reporter->delete_path" on schedule-delete items (and the current code
doesn't, AFAICT). So far, so good. But now, in svn_repos_dir_delta and
its recursive helpers, we go comparing the source and transaction trees,
and if a source entry and a target entry are both absent, we do
nothing cuz there's nothing to iterate over. but if the source entry
is absent because it was *missing* (i.e., because we called
"reporter->delete_path" on it), then "doing nothing" isn't correct -- we
need to generate a "delete-entry" for that path.
so the gist of my solution is that, after we've gone through all the
normal recursion of svn_repos_dir_delta and friends, we find all the
paths that were marked as missing and, if they weren't already handled
by the existing apparatus, delete them (i think it can be shown that
this approach is correct as far as deleting the correct paths should).
and the way we find paths marked as missing is by calling
svn_fs_paths_changed on the source txn.
right now my work is too messy to show, but with a couple hours of work
(which means sometime on saturday, given my schedule) i could post
a patch for you to examine if you wish.
this is by far the deepest i've delved into subversions inner workings,
so it's entirely possible that there is some other, better solution to
issue #1075 which i haven't thought of.
> In the meantime, if your repository isn't too large, I'd appreciate it
> if you mailed me (privately) the output of `db_dump -kp
> /path/to/repos/db/changes`.
oh, here's the thing i forgot to mention: my patch, as it stands, passes
my hand-tests for the bug, and passes update-tests.py (and most of the
rest of the python test suite) -- but fails with this error in the C tests
for libsvn_repos.
weird, huh? at any rate, i don't think the repository generated by that
one test should be too big.
thanks,
brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 25 18:56:45 2003