Greg Stein <gstein@lyra.org> writes:
> 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.
I think there's a slight error here, though. If bubble up caused a
new node N' to exist in place of N, then N != N'. Specifically, N'
has at least one entry that points to a different node than that entry
pointed to in N.
So we can't just say that N' is the mutable form of N but that
otherwise N == N'. They are not equal.
(I'm also fuzzy on why you would need them to be equal; this kind of
non-equality is what fs merging is supposed to handle, right?)
> 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.
But I would think the answer is, given txn T, path P, and node N, you
can always change it -- if it's not mutable, it'll become mutable.
The point of svn txns and automatic bubble-up is to save you from
thinking about mutability (your change might conflict with some other
change in the repository, of course, but that fact is external to T).
?
-K
> > > 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