You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2015/11/16 15:34:57 UTC
svn commit: r1714595 - in /subversion/branches/move-tracking-2:
BRANCH-README notes/move-tracking/README
Author: julianfoad
Date: Mon Nov 16 14:34:57 2015
New Revision: 1714595
URL: http://svn.apache.org/viewvc?rev=1714595&view=rev
Log:
On the 'move-tracking-2' branch: Move a description of the work from
BRANCH-README to notes/move-tracking/README.
* BRANCH-README
Move most of the notes from here...
* notes/move-tracking/README
... to this new file.
Added:
subversion/branches/move-tracking-2/notes/move-tracking/README
- copied, changed from r1714534, subversion/branches/move-tracking-2/BRANCH-README
Modified:
subversion/branches/move-tracking-2/BRANCH-README
Modified: subversion/branches/move-tracking-2/BRANCH-README
URL: http://svn.apache.org/viewvc/subversion/branches/move-tracking-2/BRANCH-README?rev=1714595&r1=1714594&r2=1714595&view=diff
==============================================================================
--- subversion/branches/move-tracking-2/BRANCH-README (original)
+++ subversion/branches/move-tracking-2/BRANCH-README Mon Nov 16 14:34:57 2015
@@ -8,178 +8,4 @@ Merge policy:
is not intended to be kept in a state where it could be merged to trunk.
-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 branch:
-
- * '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.)
-
+See notes/move-tracking/README for details of this work.
Copied: subversion/branches/move-tracking-2/notes/move-tracking/README (from r1714534, subversion/branches/move-tracking-2/BRANCH-README)
URL: http://svn.apache.org/viewvc/subversion/branches/move-tracking-2/notes/move-tracking/README?p2=subversion/branches/move-tracking-2/notes/move-tracking/README&p1=subversion/branches/move-tracking-2/BRANCH-README&r1=1714534&r2=1714595&rev=1714595&view=diff
==============================================================================
--- subversion/branches/move-tracking-2/BRANCH-README (original)
+++ subversion/branches/move-tracking-2/notes/move-tracking/README Mon Nov 16 14:34:57 2015
@@ -1,12 +1,13 @@
-A branch on which to prototype a model of move-tracking and branching.
+Experimental work to prototype a model of move-tracking and branching
+is mostly contained in:
-Merge policy:
-
- Development branch -- periodic catch-up merges from trunk.
-
- The work on this branch may or may not eventually be wanted on trunk. It
- is not intended to be kept in a state where it could be merged to trunk.
+ 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:
@@ -35,7 +36,7 @@ The model:
for a description.
-Work on this branch:
+Work on this experiment:
* 'svnmover'