Philip Martin <philip@codematters.co.uk> writes:
> > + I'm looking over the history of this issuue, and over the access baton
> > + code, and trying to wrap my brain around things. Probably I'm just
> > + being dense, but right now only the "write to tmp area then have a log
> > + command move the tmp/wcprop to the real wcprop" solution is coming to
> > + mind.
>
> You need to defer the log file, which means you need to keep track of
> whether it is required, and you don't want to rely on the presence of
> the tmp file as it could be out of date. So you create the tmp file,
> and you record the fact in memory in the access baton. Then when you
> create the deferred log file you query the access baton to determine
> if the tmp file is valid.
Okay, gotcha.
I think we can do without the tmpfile entirely, by just storing the
property and new value in the log item itself. But you're right, we
need to defer it, because the whole point is that we can't write the
wcprop command to the logfile until all other commit-related log
commands have been written.
So, one solution might be to have a field in the access baton that
stores deferred log items. When one invokes
svn_wc__run_log (adm_access, pool);
it would first take everything pent up in adm_access->final_log_items
(or whatever) and append it to the log, atomically of course, *then*
run the log.
Any holes in that?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 26 00:25:11 2002