RE: fs-atomic-renames: Soft moves?

> Now, that's what creates one of these things, but why is it done that
> way?

[...]

> So what's the point here? Is this one of those cases where if we
> didn't do these gymnastics we'd end up reusing primary keys or
> something?

Yes. In short, it's to prevent a primary key conflict. Which is why
the history code ignores it.

> And if so, does the same sort of problem occur with moves
> as can happen with copies?

The problem can't be *caused* by a move like it can with a copy, because
after a move operation, the total number of nodes that could possibly
have such primary key conflicts later hasn't changed (remains 1). Copies
break the one-line-of-history-per-node-id rule. After a copy, you will
have one more node-revision whose node-id is the same as another's than
you had before the copy. So we use the soft-copy concept to ensure that
that can't lead to conflicts later -- we guarantee that even if two
node-revisions' node-ids and txn-ids are the same, at least their copy-id
component can never match.

My questions in the proposal about whether a "soft move" was needed were
due to not thinking through this quickly enough, and conflating the ideas
of a move *causing* the need for such a key-uniqueness-insurance mechanism
and simply needing one in a make_path_mutable where some parent had been
moved.
Received on Wed Mar 15 03:23:28 2006