Experimental work to prototype a model of move-tracking and branching
is mostly contained in:

  notes/move-tracking/
  subversion/include/private/svn_branch*.h, svn_element.h
  subversion/libsvn_delta/branch*.c, element.c
  subversion/tests/cmdline/svnmover_tests.py
  tools/dev/svnmover/

This work started out on the 'move-tracking-2' branch.

Reviewing:

  Please do try out the 'svnmover' utility, explore how branching and
  subbranching and moving interact, and review and discuss the behavioural
  aspects of the model being prototyped here.

  Please don't review for 'quality of implementation' issues, not even
  big-O complexity concerns etc. The goal of this work is for us to learn
  about the behavioural model that we want. Designing a proper
  implementation will come later.


The model:

    Imagine a user who:

      - is familiar with version control concepts
      - is not familiar with Subversion specifics
      - expects directories to be versioned (not just files)
      - expects move tracking (as opposed to move 'detection')

    The design aims to satisfy such a user.

    See 'notes/move-tracking/element-model/moves-element-model.html'
    for a description.


Work on this experiment:

  * 'svnmover'

    A proof-of-concept utility for playing with moves and branching.
    'svnmover' is a user interface that lets us try out scenarios in
    which branching and moving are significant, to see what we expect
    and see if we can write code that delivers it.

    'svnmover' operates directly on a repo, like 'svnmucc', without using
    a working copy on disk. However, it simulates a short-lived working
    copy, in memory. It processes a series of commands given on the command
    line or interactively. These commands change the state of the simulated
    WC. The changes are committed on exit or whenever the 'commit' command
    is given.

    Advanced working copy facilities -- mixed-rev states, sparse checkouts,
    conflicts, and so on -- are initially not supported. Such facilities
    may be introduced to 'svnmover' in due course in order to explore how
    they would work.

    (A working copy is, in essence, a tool for viewing and making changes
    to the versioned data, and so its facilities need to be redesigned to
    support the new versioned data model.)

    The implementation stores metadata either in revprops or in flat files
    in the repository directory; the metadata is the same in either case.

    STATUS

    This is my current focus.

    Implemented:
      basic edits: add file/dir, move, copy, delete
      branching: branch, create new branch, list branches
      diff
      merge
      commit
      update, switch
      revert

    UI things to do:

      add a 'parallel mode' UI as an alternative to the sequential mode
        - started, by removing the automatic commit after each line
        - look up given paths in the base state rather than in the current txn
        - this would make more sense in conjunction with element-addressing UI

      provide a way to specify a mixed-rev base state

      provide a UI for element-based addressing ('mv e101:foo e103:foo'?)

      "mktbranch" -- make a new (empty, unrelated) top-level branch

      "rmtbranch" -- remove a top-level branch

    Bigger things to do:

      heuristic conversion of old repositories:
        synthesize element tracking info (instead of aborting) when reading
        a revision that was committed by a non-move-tracking client
          - Started, by using log scanning code from the 'moves-scan-log'
            branch and starting to write an Ev1-to-Ev3 converter that uses
            that info.
          - Currently triggered by a 'migrate' subcommand.

      Make machine parsable serial input and output for diffs etc.
        - This may help with prototyping by allowing easier connection to
          external scripts etc.

      Persist WC on disk.

    Tidying things to do:

      (none listed)

  * The model.

    To do:

    - clarify the sequencing requirements of editing: for example,
        requesting the full path to an element implies finalization of
        at least it and all its parent elements

        The editor currently includes a 'sequence_point' method.
        This is a broken bit of design. It was an attempt to allow
        'flattening' the txn state into a tree on demand, so the client
        (especially a client like svnmover) can query the txn by path.

        The client should never make a query that involves paths on a
        txn that is in an arbitrary state (some elements edited, some
        yet to be edited).

        The 'sequence_point' method should go away.
        Instead, the client should request a (read-only) snapshot of
        the state (e.g. svn_branch_subtree_t) at an appropriate time,
        and query that.

        Any 'svn_branch' APIs that look up by path or yield a path
        should not be used on a txn in an arbitrary state, but only on
        a 'flat' snapshot state (e.g. svn_branch_subtree_t).

        Need to decide whether to use a single data type for both
        txn and flat-tree, or separate types as currently done
        ('svn_branch_state_t' and 'svn_branch_subtree_t'), and go
        fully with whichever way we decide.

      copying: model copying as a (tree) relationship between elements
        that is the same across all branches in a family?


STRUCTURE

    svn_element.h

        Defines the 'element' and other basic concepts including 'payload'
        (files and directories), identifiers, etc.

    svn_branch.h:

        svn_branch_txn_t: a transaction that defines a new 'commit',
        or 'head' state, based on a previous one

        svn_branch_state_t: defines the state of one branch

    svn_branch_nested.h

        Redefines 'branch txn' to support nesting of branches.

    svn_branch_repos.h

        Access to revisions in a repository.

    The 'branch txn' can be used for commit, in which it represents a new
    head revision based on a previous revision.

    The 'branch txn' can be used for updating a WC. The WC contains a base
    state and a txn that represents the working state relative to the base
    state. (This txn is persistent on disk.) To update the WC to a new base
    state, we first build a new transaction in the WC to represent the new
    base state, based on the old base state. Then we merge these two txns
    to produce the txn that represents the new working state.

    (The original 'update editor' had a peculiarity in that it used the
    same API underneath but operating on WC paths rather than repository
    paths/nodes. We should try to use exactly the same API for update,
    commit, diff, merge, etc. as far as possible.)