commit logic.

I assume you all saw the bug that Fitz posted and Mike analyzed.

Namely, if your wc is at revision 1, *except* for `iota', which is at
revision 2, and then you try to commit a local mod on iota -- you get
an error.

Mike correctly analyzed the problem: the fs commit editor is
currently operating under the assumption that the commit is happening
on a single pristine tree. We haven't taught it how to deal with a
mixed-revision working copy yet. (We've been planning to. :))

But this is *exactly* the problem that Jim and I talked on the phone
about, and then I argued with Karl about. I still don't understand
the resolution to this problem. Jim and I came up with something, I
think, but then Karl pointed out that the problem isn't fixed.

We need to talk about this.

----------------------------

If I'm committing on transaction that is originally based on revision
1, and suddenly the client calls replace_file(baserev=2), what is the
proper behavior?

Ben's first instinct was: oh, in that case, replace_file should do an
fs_copy of the the immutable node 2:/path/to/iota into our transaction.

Jim's argument was: but how do we know that 2:/path/to/iota even
exists? Somebody may have renamed iota's parent dir in rev. 2!

Jim's solution was: punt on the problem, and instead declare that
replace_file() was called erroneously. New rule that editor-drivers
must follow: if you try to commit a target that it at a "unexpected"
rev, (i.e. a rev you wouldn't expect to find in a parent of a
different rev) then the driver must call delete(iota), and then
add_file(iota, copyfrom=2:/path/to/iota).

Karl's objection was: I don't see how this solves the problem. The
client *still* doesn't know that 2:/path/to/iota exists. Calling
{delete, add} has the exact same effect on the transaction as if
replace_file() had called {fs_copy}, and the same set of assumptions.

Ben's thought is: The user ended up with rev.2 of iota in one of two
ways:

    1. he committed iota, creating revision 2 in the fs.

    2. he did an `svn update iota'.

In case 1, we *know* that 2:/path/to/iota exists, so we're ok.

In case 2, we don't know that the path exists. BUT: I ask here --
if, when somebody else created revision 2, renamed one of iota's
parent dirs, wouldn't the update command fail in the first place?
Wouldn't the user get an error saying

   "sorry, I can't update iota for you. because I can't find
    /path/to/iota in the head revision. One of iota's parents is
    out-of-date; please update at a higher point in your working
    copy."

Once again, we come back to the issue of how to do partial updates.
Ugh. :)
Received on Sat Oct 21 14:36:26 2006