cmpilato@collab.net writes:
> Currently, mod_dav_svn is sending reponses back during the commit
> process to the client for things which we generally don't want to
> "bump". The general rule is that we only bump directories if they are
> committed objects, and that only occurs when a property of that
> directory has been modified.
>
> I have about 60% confidence that this is the right solution, mostly
> because I'm not sure if not sending a response at all for certain
> directories is too much of an information loss from the client's point
> of view.
>
> Comments (and perhaps some honest knowledge :-) welcome.
Yeah, I agree with your other 40% :-). Too much of an information
loss. I think it would be better to solve this on the client side.
Here's why and how (along with a little more background, for those who
haven't been living and breathing this stuff for months :-) ).
Summary of the situation:
When the client commits, it sends a bunch of changes through an RA
layer to the repository. The repository "merges" these changes into
the current youngest revision X, producing the new youngest, Y. (It's
called a "merge" only because the client's working copy is probably
not completely up-to-date, so the repository has to make sure that the
changes between where the wc is and X do not conflict with the changes
being committed.)
After a successful commit, the repository sends back a "merge
response", summarizing the changes between X and Y. The RA layer
(which, remember, is running on the client side) uses this response to
invoke some revision-bumping functions provided by libsvn_wc. So if
the response claims a directory changed, perhaps because something
underneath it changed, the RA layer will faithfully call one of the
bumper functions on that directory.
The problem with this is that the working copy wants to be more
relaxed about revision bumping. It's true that in the *repository*,
some intermediate directory is now different (i.e., has a different
node-rev id, and therefore a different versioned-resource url), but in
the working copy, we can't bump that directory's revision because the
working copy allows mixed-revision directories. Otherwise, the user
would have to make their entire tree be up-to-date after every commit
-- very inconvenient.
It turns out that the only kind of commit which results in a directory
revision being bumped in the working copy is when you change the
property list of that directory. In that case, the Subversion
filesystem demands that the directory be completely up-to-date, and
therefore the working copy code can safely bump the revision after the
commit.
For every other kind of commit (added file/subdir, deleted
file/subdir, changed file, whatever), the entry for the changed entity
records its new revision, but its parent directory's revision stays
the same, since other things in that directory have not been updated.
The way to get the directory's own revision to go up is to update, not
commit.
Great. So that's the problem. The solution? Well, I don't think we
want to change the merge response -- it's accurately reporting what
happened in the repository, and we shouldn't change that report just
because Subversion's working copies have their own more relaxed set of
rules about how things should be.
Instead, we can do one of two things:
SOMEWHAT CLEAN:
Change the code in the RA layer that interprets the response,
such that it doesn't invoke the bumping function so faithfully.
VERY CLEAN:
Change the *bumping* functions, which are actually part of the
working copy library and thus part of the wc semantics, to be
more sophisticated about when they bump.
Mike, I know you're probably busy with other stuff at the Brisbane
office, so Ben and I are looking at both solutions right now; watch
this space for more.
-K
> ------
>
> Index: mod_dav_svn/merge.c
> ===================================================================
> --- mod_dav_svn/.svn/text-base/merge.c Wed Oct 3 15:14:13 2001
> +++ mod_dav_svn/merge.c Tue Oct 16 13:40:47 2001
> @@ -179,18 +179,6 @@
> return NULL;
> }
>
> -static svn_error_t *mr_delete_entry(svn_stringbuf_t *name,
> - void *parent_baton)
> -{
> - mr_baton *parent = parent_baton;
> -
> - /* Removing an item is an explicit change to the parent. Mark it so the
> - client will get the data on the new parent. */
> - parent->seen_change = TRUE;
> -
> - return NULL;
> -}
> -
> static svn_error_t *mr_add_directory(svn_stringbuf_t *name,
> void *parent_baton,
> svn_stringbuf_t *copyfrom_path,
> @@ -206,10 +194,6 @@
>
> /* the response for this directory will occur at close_directory time */
>
> - /* Adding a subdir is an explicit change to the parent. Mark it so the
> - client will get the data on the new parent. */
> - parent->seen_change = TRUE;
> -
> *child_baton = subdir;
> return NULL;
> }
> @@ -269,10 +253,6 @@
>
> /* We wait until close_file to issue a response for this. */
>
> - /* Adding a file is an explicit change to the parent. Mark it so the
> - client will get the data on the new parent. */
> - parent->seen_change = TRUE;
> -
> *file_baton = file;
> return NULL;
> }
> @@ -388,7 +368,6 @@
> /* set up the editor for the delta process */
> editor = svn_delta_default_editor(pool);
> editor->replace_root = mr_replace_root;
> - editor->delete_entry = mr_delete_entry;
> editor->add_directory = mr_add_directory;
> editor->replace_directory = mr_replace_directory;
> editor->change_dir_prop = mr_change_dir_prop;
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
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:44 2006