On Sat, Jun 09, 2012 at 10:09:13PM -0000, rhuijben_at_apache.org wrote:
> Author: rhuijben
> Date: Sat Jun 9 22:09:13 2012
> New Revision: 1348513
>
> URL: http://svn.apache.org/viewvc?rev=1348513&view=rev
> Log:
> * notes/wc-ng/conflict-storage-2.0
> Add some initial design of a simple but extensible skel based conflict store,
> written down over the last few days.
Hi Bert,
I've skimmed this proposal, and I do think it would be a good way
forward without any obvious drawbacks. What are your plans on getting
this implemented in time for 1.8? Do you need help with this?
>
> Added:
> subversion/trunk/notes/wc-ng/conflict-storage-2.0 (with props)
>
> Added: subversion/trunk/notes/wc-ng/conflict-storage-2.0
> URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/conflict-storage-2.0?rev=1348513&view=auto
> ==============================================================================
> --- subversion/trunk/notes/wc-ng/conflict-storage-2.0 (added)
> +++ subversion/trunk/notes/wc-ng/conflict-storage-2.0 Sat Jun 9 22:09:13 2012
> @@ -0,0 +1,172 @@
> + -*- Text -*-
> +
> +Conflict storage 2.0/NG
> +=======================
> +
> +For WC-NG we tried to introduce a new storage model for conflicts, but we
> +didn't get this proposal completed for Subversion 1.7. I would like to
> +revive the new conflict storage topic with a new simple model that can
> +be extended later to allow the more advanced scenarios.
> +
> +I'm going to simplify the model described in the 'conflict-storage' document
> +a bit in an attempt to allow fitting this in the Subversion 1.8.0 release.
> +
> +
> +Current Situation
> +-----------------
> +
> +We currently support three kinds of conflicts.
> +
> + * Text conflicts
> + * Property conflicts
> + * Tree conflicts
> +
> +These conflicts all have their own storage model.
> +
> +Text conflicts are stored in the working copy in marker files. This allows
> +resolving later using the --accept argument of 'svn resolve'.
> +While resolving non-interactively we just know where these files are.
> +
> +Property conflicts are stored in a 'write only' marker file. Only --accept
> +working is really supported.
> +While resolving non-interactively we just know that there is/was some conflict.
> +
> +Tree conflicts are just stored in a skel in the ACTUAL table of wc.db. Many
> +details are available while resolving both interactively and non-interatively,
> +but we don't have the necessary logic to provide help in common user scenarios.
> +
> +In our current code a node can be tree conflicted or 'node' conflicted, but not
> +both. A 'node' conflicted node can have either text or property conflicts, or
> +both.
> +
> +Once a node is tree or 'node' conflicted, it is skipped by future update,
> +switch and merge operations so we (currently) don't have to allow layering
> +multiple conflicts of the same type while creating conflicts.
> +
> +(BH: My guess would be that resolvers might encounter such situations on multi
> + layer moves, but in that case multiple tree locations are involved. So maybe
> + we can work around that)
> +
> +Plans for the initial version
> +-----------------------------
> +
> +What I would like to introduce for 1.8 would be a unified extensible storage
> +model that allows the interactive and non-interactive resolvers access to the
> +same information. In most cases this can be accomplished by collecting the
> +information and storing it in a conflict-ng skel that can be stored in the
> +ACTUAL table, like we do for tree conflicts now.
> +
> +The Skel I would like to propose for the intial version would be
> +
> +(WHY (CONFLICT*) ...)
> +
> +Where ... is currently undefined, but explicitly free for future extension.
> +
> +
> +Where 'WHY' would tell why the conflict was introduced
> +WHY = (OPERATION (PATH_REV*) ...)
> +
> +OPERATION = "update" | "switch" | "merge" | ...
> +PATH_REV = ("subversion" repos_id repos_relpath revision kind ...) | () | ...
> +
> +repos_id, repos_relpath, revision and kind are defined as in wc-metadata.sql.
> +
> +"update" and "switch" will have 1 PATH_REV item, containing the original BASE
> +path from before the update/switch. The new location is already available in
> +BASE so doesn't have to be duplicated.
> +
> +Merge will have 2 items: the left and right paths. These can come from a
> +different repository.
> +
> +An empty skel specifies that there is no location. (Tree conflicts and/or
> +upgrade scenarios). Future versions may introduce other origins.
> +
> +CONFLICT =
> + ("text" MARKERS ...) |
> + ("prop" MARKERS (PROPS-OLD PROPS-NEW PROPS-WORKING) ...) |
> + ("tree" () LOCAL-STATE INCOMING-ACTION ...) |
> + ("..." MARKERS ...)
> +
> +A node can have more than one conflict, so this is defined to be a list.
> +Currently this will be either a tree conflict, or a 'node' conflict, that might
> +be text, prop or both.
> +
> +Every conflict has a MARKERS list
> +
> +MARKERS = (MARKER*)
> +MARKER = local_relpath | ()
> +
> +This list can either contain one or more files relative from the working copy
> +root. Marker positions can be skipped by using an empty list instead of a
> +local_relpath (Needed for some text conflict scenarios).
> +
> +For all marker lists with at least one element the rule applies: Once no
> +markers exist on disk the conflict is handled as if it is resolved.
> +(Legacy behavior of Text and Property conflicts)
> +
> +The empty list specifies that there is no such behavior (tree conflicts)
> +
> +Making these easy to parse helps the revert and copy code, that apply
> +special behavior to these files.
> +
> +
> +Text Conflicts
> +--------------
> +
> +Text conflicts are initially described as
> + ("text" MARKERS ...)
> +
> +This simple model provides all the storage of the wc-1.0 like storage and
> +while resolving we can start using the WHY information.
> +
> +svn info can provide additional information about the conflict and all the
> +svn resolve options apply in both interactive an non-interactive situations.
> +
> +The MARKERS list always has at least 3 items, where the first 3 map to OLD,
> +NEW and WORKING in the old WC-1.0 behavior. () markers are needed to keep
> +this code compatible with svn_wc_entry_t mapping.
> +
> +Using the PRISTINE store as additional backing store for text conflicts
> +is left out of this proposal and can be implemented independently.
> +
> +Property Conflicts
> +------------------
> +
> +Property conflicts are initially described as
> + ("prop" MARKERS (PROPS-OLD PROPS-NEW PROPS_WORKING) ...)
> +
> +This simple model extends the wc-1.0 model to allow the same conflict
> +resolving as for text conflicts. All the options 'base', 'working',
> +'mine-conflict', 'theirs-conflict', 'mine-full' and 'theirs-full' are
> +relatively easy to implement once we have the values stored.
> +
> +svn info can provide additional information about the conflict and all the
> +svn resolve options apply in both interactive an non-interactive situations.
> +
> +The first item in the MARKERS list is mapped into the old svn_wc_entry_t
> +structure.
> +
> +Providing a new libsvn_wc and libsvn_client API to view the three property
> +collections is outside the scope of this proposal and can be implemented
> +independently once this is implemented.
> +
> +The --accept options already provide a lot of additional value and the
> +WHY model would allow access to the specific sets by URL.
> +
> +Tree Conflicts
> +--------------
> +
> +Tree conflicts are initially described as
> + ("tree" () LOCAL-STATE INCOMING-ACTION ...)
> +
> +Tree conflicts (currently) have no marker file, so this is described as ()
> +instead of MARKERS.
> +
> +This skel together with the WHY skel provides all the currently available
> +tree conflict information and can be mapped into the old data structures.
> +
> +The current svn info behavior can be reused for the other conflict types,
> +where it applies to the WHY parts.
> +
> +It would be nice if some other --accept values would be accepted, but that
> +is outside the scope of this design.
> \ No newline at end of file
>
> Propchange: subversion/trunk/notes/wc-ng/conflict-storage-2.0
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
Received on 2012-06-26 17:09:55 CEST