Re: CVS update: subversion/subversion/mod_dav_svn version.c

This still isn't quite right. A while back, I asked about an FS API function
to say, "hey! can I modify this?" We punted because it seemed like a simple
ID comparison. I'm finding it isn't :-)

The additional restriction needed is to ask "is D' an immediate child of D,
*AND* is D' mutable?" It is entirely possible for somebody to try and check
out D' (due to monkeyness noted in the comment in code (not shown in the
context)), and then you have D'' when it becomes mutable.

The monkeyness is basically:

1) Jon starts a commit based on rev R
2) Jane commits a change, upping the revision to R'
3) Jon updates D to D'
4) Jon's commit, while trucking along needs to do a DAV CHECKOUT on D' to
   make some changes
   ==> the old code punted (restart the commit (based on R'), hoser). after
       this change, it gets through. this may work, maybe not. need to apply
       heavy brain power.

Ah well... with this, my complex commit is moving along better, but now it
looks like somebody destroyed a pool on me. Rebuilding the world with
pool debugging enabled...

Cheers,
-g

On Tue, Apr 17, 2001 at 12:58:23AM -0000, gstein@tigris.org wrote:
> User: gstein
> Date: 01/04/16 17:58:23
>
> Modified: subversion/mod_dav_svn version.c
> Log:
> In certain cases, two collection nodes should be treated as equivalent.
> Don't reject this case when a CHECKOUT occurs.
>
> (dav_svn_checkout): check for an immediate parent/child relationship between
> the requested node ID and the transaction's ID. this "change" occurs
> during bubble up scenarios, but also during normal processing (yet it
> would be impossible for a client to specify the node in the txn, so even
> if the node has real changes, they should be considered equivalent
> (although real changes should not have happened before a checkout...))
>
> Revision Changes Path
> 1.25 +37 -8 subversion/subversion/mod_dav_svn/version.c
>
> Index: version.c
> ===================================================================
> RCS file: /cvs/subversion/subversion/mod_dav_svn/version.c,v
> retrieving revision 1.24
> retrieving revision 1.25
> diff -u -r1.24 -r1.25
> --- version.c 2001/04/16 11:31:34 1.24
> +++ version.c 2001/04/17 00:58:22 1.25
> @@ -246,6 +246,8 @@
>
> if (!svn_fs_id_eq(res_id, resource->info->node_id))
> {
> + svn_boolean_t invalid = TRUE;
> +
> /* If the version resource is *newer* than the transaction
> root, then the client started a commit, a new revision was
> created within the repository, the client fetched the new
> @@ -258,15 +260,42 @@
> that. We can stop the commit, and everything will be fine
> again if the user simply restarts it (because we'll use
> that new revision as the transaction root, thus incorporating
> - the new resource). */
> + the new resource).
> +
> + Special exception case:
> +
> + If the nodes are directories, and the transaction's node is
> + an immediate child of the requested node, then we're okay.
> + The issue is that we generate a child for the directory when
> + it goes from an immutable node in a revision root, into a
> + mutable node in the transaction root. We should not consider
> + this a change, and there would be no way for the client to
> + check out the transaction root's directory node anyway.
> +
> + Files do not have this behavior because they are not spuriously
> + placed into the transaction root (directories are because of
> + the bubble up algorithm). The only time a file will shift is
> + when a true change is being made, and we'll see that anyways.
> + */
> + if (svn_fs_is_parent(resource->info->node_id, res_id))
> + {
> + int is_dir;
> +
> + serr = svn_fs_is_dir(&is_dir, txn_root,
> + resource->info->repos_path, resource->pool);
> + if (serr == NULL)
> + invalid = !is_dir;
> + /* else ignore the error and go with the "out of date" msg */
> + }
>
> - return dav_new_error(resource->pool, HTTP_CONFLICT, 0,
> - "The version resource does not correspond "
> - "to the resource within the transaction. "
> - "Either the requested version resource is out "
> - "of date (needs to be updated), or the "
> - "requested version resource is newer than "
> - "the transaction root (restart the commit).");
> + if (invalid)
> + return dav_new_error(resource->pool, HTTP_CONFLICT, 0,
> + "The version resource does not correspond "
> + "to the resource within the transaction. "
> + "Either the requested version resource is "
> + "out of date (needs to be updated), or the "
> + "requested version resource is newer than "
> + "the transaction root (restart the commit).");
> }
> }
>
>
>
>

-- 
Greg Stein, http://www.lyra.org/