monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] New 'update <rev>' command?


From: Joel Rosdahl
Subject: Re: [Monotone-devel] New 'update <rev>' command?
Date: Sun, 21 Nov 2004 18:22:32 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)

Nathaniel Smith <address@hidden> writes:

> Heya, Joel, noticed the new version of 'update' that you added, that
> takes a revision argument. Can you describe what the intended
> semantics of this are?

With pleasure. And...

> In my head, the purpose of update is always to "move" your local
> changes so that they hang off of a different committed version -- it
> changes what you're making changes relative to. The algorithm is to
> merge3 the working directory with the target revision using the
> current base revision as the common ancestor.

...you describe the intended semantics exactly. :-)

> I'm not sure I understand what's happening in your code, but it
> doesn't look like it's doing that when a revision argument is
> applied; is it actually doing like a merge-into-working directory or
> something?

No. It's supposed to apply the changeset between the working copy's
base revision B and the target revision R to the working copy, thereby
moving the working copy's base revision to R while keeping local
changes. To get the changeset between B and R, there are four cases:

    Case 0: If common_ancestor(B, R) does not exist, then it's an
    error.

    Case 1: If common_ancestor(B, R) is B (updating to a descendent),
    then the changeset is the changeset between B and R.

    Case 2: If common_ancestor(B, R) is R (updating to an ancestor),
    then the changeset is the inverse of the changeset between R and
    B.

    Case 3: If common_ancestor(B, R) is A (updating to a revision
    reachable through a common ancestor), then the changeset is [the
    inverse of the changeset of A and B] concatenated with [the
    changeset between A and R].

(Case 1 and 2 are of course special cases of case 3, but I chose to
implement it similar to the code of the diff command.)

But I may very well have made some error. Is it something in
particular that caught your eye?

        Regards,
        Joel

-- 
Joel Rosdahl <address@hidden>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97




reply via email to

[Prev in Thread] Current Thread [Next in Thread]