Re: [Vesta-devel] Repository bug(s) => crash during checkpointing

[Kenneth C. S. <ke...@xo...>]

> Hmm, it's true that the operations are done as separate
> transactions, where the first one is something of a no-op by itself
> (adding an #owner attribute that's the same as what would be
> inherited from above), but I can't think why I would have done that.
> It would have been just as easy and less subtle to move the
> VRLog.start/commit brackets outward so that they surround both
> operations, making the attribute write nested inside the main
> transaction.  (VRLog supports that.)  Then both operations will
> commit as an atomic unit, no matter in what order they're applied to
> the in-memory structure.  [...]

> If you look at insertImmutableDirectory, there was a similar issue,
> but I did it the "right" way around there: the #owner setting is a
> nested transaction, and it's done after the insertion into the new
> parent.

I took your suggestion and changed renamerTo to make the attribute
change after the rename.  (It had gotten pretty hairy with the
copyToMutable in the middle anyway.)

After doing this, making a variety of other minor improvements, and
giving the new version a significant amount of testing, I've gone
ahead and checked into:

  /vesta/vestasys.org/vesta/repos/35.scalability/6

(I won't bother to repeat the checkin comment here, as it's
essentially all been said in this thread already.)

I would, of course appreciate comments.

--Ken

P.S. At the moment, I'm not going to patch this change into the
main-line, as I'm trying to focus on getting the repos/35.scalability
branch cleaned up and moved to the next main-line version anyway.