On Thu, Jul 18, 2002 at 12:43:17AM -0500, Karl Fogel wrote:
>...
> Well, if we want to do that, we should just have F write out the
> wcprop changes to a tmp area, the same as is done with text-base.
Yes. This is needed regardless since we have to put the changed property
*somewhere*.
> Then svn_wc_process_committed writes a special log item to the log, as
> part of the appropriate transacted group of log appends. This log
> item says to go look in the tmp place for any wcprop changes, and
> process them. When the log is run, the wcprop changes will be picked
> up *as part of the correct group*.
Nope. We can't wait this long. Something has to go into the log right away.
Consider the following process:
* RA writes some new props for FOO into tmp/queued-props/FOO
* server rejects a change to BAR, process_committed does not get run
* user reverts changes on FOO and BAR
:
time passes
:
* RA writes some props for FOO into tmp/queued-props/FOO
* process_committed adds a log command to incorporate the props
* the log is run and the props are incorporated
In our *current* scheme, this will be fine because the writes that occur in
the second operation overwrite the first set. But what if they are disjoint?
That means we've incorporated a good set *and* a bad set.
So... the answer is that *some* kind of record needs to go in right away so
that a failed commit can clean up the garbaged stuff. However, I am showing
some ignorance here. Just how does the tmp area get cleaned? Do we simply
delete all contents before unlocking the directory? Or do we really need to
leave a log command that identifies the file, and our cleanup goes over the
log and says "oh. there is a file to toss." ?
[ iow, I don't know how we cleanup after a failed commit, or when somebody
runs 'svn cleanup' ]
If the tmp gets totally cleared all the time, then we might be okay.
I'm just a bit shaky about "leaving this thing around to be magically picked
up later", rather than specifically identifying "hey. there is something
right *there* to deal with"
> The important thing is, those wcprop changes can be sitting there in
> the tmp area and mean absolutely *nothing* until that log item is
> written. They are in no danger of taking effect until there's
> something in the log that says to use them. And libsvn_wc will only
> tack on that log item when it knows it is safe to do so.
Seems kind of fine, but it is shaky and really depends on *other* behaviors
in the system to ensure stuff gets cleaned up properly. A specific marker
about the file's existence is also a marker that it needs to get cleaned.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 21:02:48 2002