On Thu, Oct 18, 2001 at 03:11:36PM -0500, Ben Collins-Sussman wrote:
> Greg Stein <email@example.com> writes:
> > > Specifically, the "working" revision of the directory needs to be
> > > sent in the PROPPATCH request body. mod_dav_svn can then look at
> > > the node-rev-id of the latest version of the directory, see what
> > > revision it was *created* in (it's part of the skel), and compare
> > > it to the "working" revision from the client. It's an easy
> > > out-of-dateness check that requires no undeltifying, and is a
> > > foreshadowing of the commit-system of the future. :-)
> > No. You cannot send the working revision in the body. Blech.
> > A CHECKOUT is performed before doing the PROPPATCH. That checkout uses the
> > version url from when the directory was initially checked out. The system
> > should have punted on that initial CHECKOUT. If it didn't, then the question
> > is "why?"
> The "system"? Do you mean client, or server?
Both. All parts that comprise the system. In this case, it would really be
mod_dav_svn that punted on the CHECKOUT.
> How could either system know to punt?
> I mean, directory CHECKOUTS are done all the time -- not just before
> proppatching a directory, but anytime we edit a file too (the file's
> parent is checked out first.)
We never do a CHECKOUT on the parent directory to edit a file. We check out
the file itself, then PUT changes or PROPPATCH props.
The parent is checked out when we add or delete files.
> So -- if the server receives a PROPPATCH on a directory, is there any
> way mod_dav_svn can "recall" the vsn_url that was used to initially
> checkout the directory? If so, it can examine the vsn_url and reject
> the PROPPATCH as out-of-date.
Hmm. So the problem is that we need to allow out-of-date checkouts cuz of
the add/delete problem. On the other hand, we must enforce them for a
That seems like the crux of the problem, no?
p.s. either way: passing info during PROPPATCH is wrong
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:45 2006