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

Re: svn commit: rev 2555 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client trunk/subversion/libsvn_ra_dav

From: <cmpilato_at_collab.net>
Date: 2002-07-17 18:06:59 CEST

Greg Stein <gstein@lyra.org> writes:

> On Tue, Jul 16, 2002 at 10:09:09PM -0500, Karl Fogel wrote:
> > cmpilato@collab.net writes:
> > > > How do the entries get out of sync? I don't understand how that could
> > > > possibly happen. ???
> > >
> > > handle_resource() in ra_dav's merge.c is using bump_resource() to
> > > call the set_wc_prop callback and change the vsn-rsrc-urls. Then,
> > > after ra_dav completes entirely, control returns to the client's
> > > commit.c, where svn_wc_process_committed() is called to change the
> > > actual entries files.
> >
> > ... So if the client crashes at (say) the beginning of
> > svn_wc_process_committed(), then the vsn-rsrc-url will be out-of-sync
> > with the entry and the text-base, because process_committed takes care
> > of both of those after a commit.
> >
> > See http://subversion.tigris.org/issues/show_bug.cgi?id=797 for
> > details.
>
> Much of that wasn't in there when I looked.
>
> Okay... that clears it up, but I dislike the solution. You're compensating
> for a broken loggy system. We've got code to retain integrity, but it is
> broken. You've added yet another field to try and keep in sync, but it isn't
> necessary if you simply have a proper synchronization system in the logging
> code.
>
> For example, the bug states that logging wcprops isn't sufficient because
> you could end up running the log which would alter the wcprop, but not the
> entry. Hello? Why are we running the log if it isn't complete? That is
> suspicious right there.
>
> So now we have a bunch of new RA logic to deal with bugs in the logging
> system. But the logging system is still broken, and the RA logic still might
> not be enough to compensate for problems in the logging. Bleh.

Hm. The way I see it, now we have a bunch of new RA logic to enable
ra_dav to validate its own cached props -- something that it could
have (should have?) already been doing ... except for the fact that
its prop values are all opaque to itself and everyone else on the
client side. The code that Karl added is nothing more than ra_dav
writing out a revision prop to compensate for that fact that, despite
having *just written* out the same (or effectively the same) revision
as a piece of vsn-rsrc-url, it doesn't even realize it has done this.

Another suggestion that got tossed around -- let mod_dav_svn send back
to ra_dav a URL template so that ra_dav can learn how to build its own
darned vsn-rsrc-urls, and get rid of those cache urls altogether.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 17 18:09:44 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.