Ben Collins-Sussman <sussman@newton.ch.collab.net> writes:
> 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.
This was Mike's first thought after a night of sleep. And until
reading your mail, Ben, I had started to believe that I *was*
qualified to fix this bug! :-)
> 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!
This is a serious bug that needs to be addressed yesterday, which is
to say, regardless the proper solution to the unexpected revision
number issue, it is unacceptable to have an error message as obscure
as "Delta source ended unexpectedly" come out of this situation. I
spent over an hour looking into this from the delta point of view
before realizing what was really going on. Right now, we have no
immediate support for the rename action anyway.
> 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."
This is my thinking as well.
Received on Sat Oct 21 14:36:26 2006