Re: Rename tracking - client side

I (Julian Foad) wrote:
> [...] I've just discovered issue #3630 "Rename tracking" and
> its dependants, and will read them. I think "Rename tracking" is a good
> name. [...]

I made a start on documenting what's needed for the client side of
rename tracking (issue #3631):

[[[
* notes/rename-tracking/renames-client-side.txt
  New file.
]]]

[[[
             CLIENT-SIDE TRACKING OF RENAMES
             ===============================

CONTENTS

    1. Introduction

    2. Behaviour of Local Renames

    3. Behaviour of Incoming Renames

    4. Copies

1. Introduction

    See issue #3631, "Client-side tracking of renames", and issue #3630,
    "Rename tracking".

    This document specifies the desired client-side behaviour for tracking
    a rename.

    A local, scheduled rename can result from a Subversion "rename" command
    or from an incoming rename during an update, switch or merge. The
    behaviour of local renames is specified in section 2.

    The other necessary part of client-side behaviour is handling an
    incoming rename during an update, switch or merge. That behaviour is
    specified in section 3.

    A. What is a Rename?

        A "rename" operation moves a node from one path to another, in a
        single operation. The original node is then in a different
        directory and/or has a new name within its directory.

        No distinction is made between the words "rename" and "move": either
        word refers to the operation that moves a node to a different
        directory and/or changes its base name.

        No distinction is made between renaming a file, a directory or a
        symlink, unless otherwise noted.

        A rename cannot change the node kind.

        A node can be renamed and edited in the same change.

    B. What is New?

        The rename operation can be viewed as having two halves - removal
        from the source path, and adding or copying to the target path - but
        unlike in previous versions of Subversion, these two actions are:

          - atomic (indivisible), and

          - not quite the same as the separate "svn delete" and "svn copy"
            operations.

        The rename is remembered and propagated as a rename. One result is
        that when a node 'foo' is renamed to 'bar' in branch B1 and that
        change is then merged to branch B2, the corresponding node 'foo' in
        branch B2 is renamed to 'bar'. In previous version of Subversion,
        that did not happen; instead, node 'foo' in B2 was deleted and then
        a new node 'bar' was created in B2 by copying the original 'foo'
        from B1.

2. Behaviour of Local Renames

    A local rename is a scheduled change in the working copy.

    A. Atomicity

        - commit either path: fail, or commit both halves (TBD)

        - resolve either path: fail, or resolve both halves (TBD)

        - revert either path: fail, or revert both halves (TBD)

        - merge from either path: fail, or include both halves (TBD)

        - update/switch: fail, or include both halves (TBD)

        - changelist: ?

        - export: ?

        - lock/unlock: ?

        - ...

    B. Incoming edits (from update/switch/merge)

       Here, "edit" means any modification including a property change or,
       for a directory, an add or delete or edit of a child.

        - Incoming edit to the source path of any rename (even if a
          replacement node exists at that path): apply to the target path.
          ### Or tree conflict if a replacement node exists?

        - Incoming edit to the target path: tree conflict (?) (not possible
          with up/sw)

        - Incoming add at the source path: tree conflict.

        - Incoming add at the target path: tree conflict.

        - Incoming delete of the source path: tree conflict.

        - Incoming delete of the target path: tree conflict.

        - For incoming renames, and cases where there is both an incoming
          rename and a local rename, see section 3.

    C. Commit

        - Transmit the rename information to the server.

        - See issue #3632, "Subversion's RA subsystem should carry rename
          information".

    D. Other WC commands

        - copy from source path: fail (can't reference a gone-away node)

        - copy from target path: record as copy of that target path? (can we
          guarantee ordering such that that will be propagated correctly?)

        - copy/move a dir with a whole rename inside it: DTRT (ordering?)

        - delete target path: convert the rename into a delete.

        - info: on source node, display the target path; on target path,
          indicate it is a tracked rename

        - rename from source path: fail (can't reference a gone-away node)
          (unless the source has since been replaced by a new node, in which
          case that new node is referenced)

        - rename from target path: adapt the original rename

        - status: indicate source and target paths are parts of a rename

        - ...

3. Behaviour of Incoming Renames

    An incoming rename is a rename described to the client by the server
    during an update, switch or merge operation.

    A. Automatically merge the incoming rename with the local working copy,
       if possible. If not possible, raise a tree conflict.

        - Incoming rename, identical to a local rename: merge the two
          identical changes and unschedule the local rename

        - Incoming rename, where source is source of a local rename:
          adjust the local rename accordingly

        - Incoming rename, where target is target of a local rename:
          tree conflict

        - Incoming rename, where source is target of a local rename:
          tree conflict (not possible for up/sw)

        - Incoming rename, where target is source of a local rename:
          tree conflict (not possible for up/sw)

        - Incoming rename, local edit: rename the local node, keeping the
          local edits (including any unversioned nodes in it, if it's a dir)

        - Incoming rename, local delete: tree conflict

    B. Source of Information on Incoming Renames

        - The intended source is from an updated RA interface. See issue
          #3632, "Subversion's RA subsystem should carry rename information"

        - A possible backward compatibility measure, when talking to servers
          that do not support rename tracking, could be to infer renames
          from heuristics on incoming deletes and copies.

4. Copies

    ### TO DO

    Copies should exhibit behaviour in line with renames. During a merge,
    an incoming copy should result in a local copy from a local source,
    rather than a local copy from a source in the source branch. ...

]]]

- Julian
Received on 2010-05-28 19:00:20 CEST