On Sat, Jun 09, 2012 at 10:09:13PM -0000, [email protected] 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 >
