Re: impending change #2...

Ben Collins-Sussman <sussman@newton.ch.collab.net> writes:

> I think this system is fundamentally better than the old idea --
> whereby the client is the thing that ultimately decides which items to
> bump after the update completes.

Sorry, let me clear up the confusion this may have caused. The
paragraph above is *not* a reason in itself for switching to the
"tgt_rev in every replace() call" scenario.

I'll try FAQ style. :)

*** "In the commit case, why should the RA layer bump revisions
     after the commit is done? Shouldn't the client do this?"

It turns out that the RA layer *has* to store special WC properties
after a commit is finished. This means that the RA layer *has* to be
tracking committed targets.

In the status quo, the client is also tracking committed targets;
when the commit is done, it loops over the targets to bump revisions.

But since the RA layer is tracking committed targets anyway, it might
as well save the client some work; let it set WC properties *and*
bump revisions.

*** "Why are the tgt_rev arguments part of every replace() call now,
    instead of having set_tgt_rev() called on certain batons?"

See Karl's previous mail; it's a royal pain to produce XML if tgt_rev
isn't part of replace_*().

*** "In the update case, why should the RA layer bump revisions as
     it's driving the update-editor?"

Well gee, as long as we now have tgt_rev built-in to every replace()
call, we may as well make intelligent use of it, no? It's a perfect
way for the RA layer to communicate whether a update target should be
revison-bumped or not.

I mean, the client still *could* do all the bumping after the update
is done, but why ignore a good interface?
Received on Sat Oct 21 14:36:21 2006