# # # add_file "wiki/OverwritableNegatableOptions.mdwn" # content [7aa8dcd3f42c2cb7250c758ea671a1f6ebf39b88] # # add_file "wiki/UpdateConflicts.mdwn" # content [8fd7c68b4c0435e84777c052d3932c8ac1e003b3] # # patch "wiki/RoadMap.mdwn" # from [f6d57ab5847ad57221114613ed99f8122b6a9f2b] # to [a6a296d0317faeee1ff69f9f1be9138717595753] # # patch "wiki/ZipperMerge.mdwn" # from [9355e9616682786697c2b0f3b2e1de234755d5bb] # to [18ad52b72edda5ab76cfa222f98bb3fb99ed1962] # ============================================================ --- wiki/OverwritableNegatableOptions.mdwn 7aa8dcd3f42c2cb7250c758ea671a1f6ebf39b88 +++ wiki/OverwritableNegatableOptions.mdwn 7aa8dcd3f42c2cb7250c758ea671a1f6ebf39b88 @@ -0,0 +1,30 @@ +Implement --no- for all Boolean options (by an automatic mechanism, +not manually). Allow options specified on the command line to override +options specified in hooks or _MTN/options, or earlier in the command +line. + +For example, given the options '--foo --no-foo --foo', '--foo' is used +for the command. + +One motivation for this is to allow users to set their preferred +default options in a hook, and then easily override them as needed. +That makes it less significant what mtn sets as the default. + +For example (taken from [bug 17878] +(https://savannah.nongnu.org/bugs/?func=detailitem&item_id=17878#options), +[monotone-devel](http://lists.nongnu.org/archive/html/monotone-devel/2010-05/msg00118.html)), +many commands (approve, disapprove, pull, merge, etc) take an option +"--update", that updates the current workspace. If you always want +this behavior, you can define the get_default_command_options(cmd) +hook in your monotonerc. However, you then have no way to disable that +behavior for a particular command; you can't specify --no-update. + +There is --no-workspace, but that's not the exact negation of +--update; it has other effects (you need to specify the db and branch, +for example). + +Another example: [monotone-devel] +(http://lists.nongnu.org/archive/html/monotone-devel/2010-05/msg00138.html) +'mtn add' is non-recursive by default but allows for --recursive. If +you put this in get_default_command_options(cmd), there is no way to +override it. ============================================================ --- wiki/UpdateConflicts.mdwn 8fd7c68b4c0435e84777c052d3932c8ac1e003b3 +++ wiki/UpdateConflicts.mdwn 8fd7c68b4c0435e84777c052d3932c8ac1e003b3 @@ -0,0 +1,18 @@ +Improve the way workspace conflicts that occur during Update are +handled. + +Previous approaches have involved interactive solutions (pop up an +external file merger), or adding conflicting files in the +workspace ([[ConflictFixupPolicy]], [[MergeViaWorkingDir]]), to be +cleaned up by the user later. + +Here we propose a different approach, extending 'mtn conflicts' to +handle workspace conflicts. + +The process is to first identify all conflicts in a proposed update, +and then provide a mechanism to specify resolutions for each of them. +After all resolutions are specified, the update can take place. + +see also [[WorkspaceConflicts]] +see also [[NonMergeConflicts]] + ============================================================ --- wiki/RoadMap.mdwn f6d57ab5847ad57221114613ed99f8122b6a9f2b +++ wiki/RoadMap.mdwn a6a296d0317faeee1ff69f9f1be9138717595753 @@ -10,7 +10,7 @@ Fix `rename foo foo` | n/a | `nvm.bugfes netsync --anonymous | n/a | `nvm.bugfest-2010.28805-rlevitte` | in development | Fix `rename foo foo` | n/a | `nvm.bugfest-2010.29484-rlevitte` | in development | `kill_certs_locally` | n/a | `nvm.kill_certs_locally` | in development | -Overwritable, negatable options | n/a | n/a | not started | +Overwritable, negatable options | [[OverwritableNegatableOptions]] | n/a | not started | Fix mtn:// sync | n/a | `nvm.connection_info_cleanup` | in development | Branch name deprecation | [monotone-devel](http://article.gmane.org/gmane.comp.version-control.monotone.devel/17117/match=netsync+connection+info+cleanup) | n/a | not started | """ ]] @@ -43,7 +43,7 @@ Netsync preview | n/a | n/a | not starte 'mountpoint' node type | n/a | n/a | not started | Yes - revision format change | Command naming cleanup | n/a | n/a | not started | Probably - if sufficiently extensive, or it touches the automate commands | Netsync preview | n/a | n/a | not started | No - I don't think this would need any on-the-wire changes at all | -Update conflict handling | n/a | n/a | not started | ??? | +Update conflict handling | UpdateConflicts | n/a | not started | No | Allow `-` and `_` interchangeably in commands and options | n/a | n/a | not started | No | """ ]] ============================================================ --- wiki/ZipperMerge.mdwn 9355e9616682786697c2b0f3b2e1de234755d5bb +++ wiki/ZipperMerge.mdwn 18ad52b72edda5ab76cfa222f98bb3fb99ed1962 @@ -138,8 +138,9 @@ pick useful nodes to zipper together, an can be **very** helpful to look at diffs along each side, pick useful nodes to zipper together, and follow your progress. -A good interactive merge assistance tool is also invaluable for -each of the small merges. +A good interactive merge assistance tool is also invaluable for each +of the small merges. Alternately, 'mtn conflicts' can be used to +resolve conflicts non-interactively. See [[InterfacesFrontendsAndTools]] for tools that can help with both. @@ -151,13 +152,17 @@ and is a different user interface to the a different approach to the same problem. This is known as a workspace merge, or [[MergeViaWorkingDir]] and is a different user interface to the underlying merge algorithms. -Zipper Merge has the advantage of being available now. But even when we -have a WorkspaceMerge, the Zipper Merge usage pattern will retain its other advantages. Whichever user interface you prefer, large merges will probably still be best handled in this progressive +Zipper Merge has the advantage of being available now. But even when +we have a WorkspaceMerge, the Zipper Merge usage pattern will retain +its other advantages. Whichever user interface you prefer, large +merges will probably still be best handled in this progressive incremental style within the DAG structure. -Enhancements could be made to add a reasonable amount of smarts -in the tool to support a zipper_merge workflow or commmand - for -example, helping to automate the process of picking intermediate nodes to merge, rather than using manual inspection of the tree with a viualisation tool. When a conflict is detected, monotone could find the nodes that -introduced the conflict higher up the tree, rather than trying to -merge the current heads that have inherited this conflict as well as -others. +Enhancements could be made to add a reasonable amount of smarts in the +tool to support a zipper_merge workflow or commmand - for example, +helping to automate the process of picking intermediate nodes to +merge, rather than using manual inspection of the tree with a +viualisation tool. When a conflict is detected, monotone could find +the nodes that introduced the conflict higher up the tree, rather than +trying to merge the current heads that have inherited this conflict as +well as others.