[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-04-17 08:30:27 CEST

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.

> 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.
Received on Sat Oct 21 14:36:28 2006

This is an archived mail posted to the Subversion Dev mailing list.