Great. Just phoned Karl, and he agrees with this analysis. Mike,
either one of us can fix the bug just as we would expect to. Go ahead
and assume that replace_*() functions need to call fs_copy when they
get an unexpected base_rev argument. (And don't forget that our
dir_batons now need to store local revision numbers too!)
cmpilato@collab.net writes:
> 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