On Tue, Apr 17, 2001 at 01:30:27AM -0500, Jim Blandy wrote:
> Greg Stein <gstein@lyra.org> writes:
> > 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.
>
> Err, mutability shouldn't be visible at all outside the svn_fs.h
> interface. Every node in a transaction can be freely changed.
I know it shouldn't be visible. But the semantic that I'm looking for has
mutability as an input.
Let me try to explain:
Given node N in revision R. Node N becomes part of txn T when T is
created, based on R.
Users says "change N". N is in T, so servers says "sure."
Alternatively, N/M is modified, and bubble up puts N' into T. Now the
user says "change N", but the server says "N != N'. go away."
In reality, N == N', it is just that N' is the mutable form of N.
In the code that I just checked in, I use svn_fs_is_parent() as a crude
mechanism for testing N == N'. The right mechanism is a function that says,
"given T, path P, and node N, can I change it?" That function can
(internally) use mutability if N' is found.
> > 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.
>
> I don't understand how this case arises. If Jon has a working copy at
> base revision B, and starts a commit, mod_dav_svn creates a
> transaction based on the current youngest revision, C. The only
> comparisons you need to worry about are the changes between B and C
> vs. the changes between B and Jon's working copy. If Jane commits a
> new revision C' after Jon creates his transaction, that's irrelevant
> to you.
No. The evil part is that Jon updates his WC to C' in another window while
the commit is operating. The commit could then say, "hey! the resource you
want to change (from C') does not match what is in the transaction (from C)"
and punts on you.
Ideally, the resources Jon is changing are equal in B and C, so the server
allows the change.
Now... back to the problem that I mentioned (due to lack of a "real N == N'
test function"). Let's say that C == B + 1. Jon submits a change to a
resource in B. The server says "in my TXN, that is C, which is a direct
child [of B], so I'll let the change occur." Whoops! Of course, the resource
in the TXN could become B+2 due to bubble up, and *then* punt. But by that
point, damage could be done. I think we have a case where a change could be
"legal" when it shouldn't.
The conditions for the false legality are slim (with an unknown impact
(haven't thought thru it entirely)), but quite present. Fine for M2, but not
for 1.0.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:28 2006