Greg Stein <gstein@lyra.org> writes:
> 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.
I don't like the solution either, but I like the alternatives even
less.
You can end up running a log at any stage, if an operation crashes and
the user later runs "svn cleanup". *All* of our logging operations
have been done a certain way so far:
- You always write new items to a log in semantically unified
groups, atomically, so that if the entire log were run
immediately afterwards, there would be no problem.
- A given operation may involve several of these groups, but that's
fine, the point is that each group stands alone, and can be "run"
without loss of wc integrity.
The solution here isn't just to "make wcprops loggy", because
libsvn_wc still has no way of knowing the *semantic* constraints of
the wcprops -- the semantics are known only by ra_dav (in this case).
The working copy library simply can't know the timing constraints
here. Maybe it's important that the version-url be written out only
after the text-base is updated. Or maybe it's the other way around.
How the heck can libsvn_wc know the answer, when it doesn't even know
what a version-url is? :-)
We're able to control timing of everything else (other prop writes,
text bases, entry fields) in libsvn_wc because libsvn_wc knows what
those things mean. It knows how a text base relates to an entry, how
the "svn:keywords" prop relates to the text base, etc. But it can't
know anything about the network layer's wcprops :-(.
> I'd say: fix the logging by adding wcprops into the mix and making it more
> transacted. Then rip out this new RA code.
I wish. But it's just not that simple. What precisely does "making
it more transacted" mean? A "transaction" involving several
operations is only helpful when there's a single entity to control the
transaction -- an entity that knows the meanings of the individual
operations inside the transaction, and so is able to group them. But
here the semantics bridge across two unrelated libraries. For some
operations it may make sense to write out certain wcprops before the
entry props, for others, after. These are things libsvn_wc just can't
know. The layer that *interprets* its wcprops has to control their
validity; it can't hand that off to a layer that knows nothing about
their semantics.
Mind you, I'm not saying I like the current solution either :-). It's
ugly, no denying it. But it *does* keep the wcprop knowledge flow
restricted to ra_dav (it's perfectly okay for an RA layer to be asking
about an item's entry committed_rev, of course -- that direction of
knowledge flow is fine).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 17 21:05:04 2002