Some commands needed modification to do something sensible in a multi-parent workspace. Here I've categorized all of the documented commands (i.e. those visible in mtn --help) with some notes on what changed and why.
Commands which have been updated to error out, and why
diff:: Requires at least one -r argument. Without an -r, what should we base the diff on? Left or right parent? The "base merge"? Revisit this after users are more engaged and we know what conflicts look like. revert:: The question is where to revert to; possibilities are similar to diff, plus there's a question of whether/when revert should undo the merge operation. update:: not worth even trying to figure out what the semantics should be. merge_into_workspace:: A revision can't have more than two parents. automate get_base_revision_id:: scripts expect just one id, but logically it should return two. *(njs: a fully canonical answer to this may have to wait until we work out exactly what conceptual model we want to use for workspace merges.)* automate inventory:: needs a format change to deal with more than one parent. *(njs: ditto)* automate attributes:: emits info about changed attributes, therefore there is a question of which parent that should be relative to. *(njs wonders if we can just ditch that part of it, but suspects tommyd wants to keep it.)* annotate:: Requires an -r argument. This is not because there's any question what it ought to do without one, but rather because the annotation engine is not prepared to deal with revisions that aren't in the database. This is a bug for both single- and multi-parent workspaces (consider the case where you have modified but not committed the file you are annotating) but is only lethal in the multi-parent case.
Commands which have been updated and work
- add, drop, rename, pivot_root
- automate get_revision
- automate get_manifest_of
- automate get_current_revision_id
- status ''(shows separate deltas vs. both sides; script authors are reminded that they should be using automate get_revision (which itself will now do things it didn't used to, but the format always allowed the possibility). Should eventually show conflicts specially.)''
- log (without command line arguments, follows both parents, just as it would for a merge node already in the database)
- list known/unknown/missing/ignored
- list changed (lists everything changed relative to either parent in one jumble, no distinctions made)
Does not operate on a workspace
Starred commands in the list below will have their semantics change later in this process, but are not affected at the present stage.
approve automate ancestors ancestry_difference certs children common_ancestors descendents erase_ancestors get_file graph heads interface_version keys leaves packet_for_fdata packet_for_fdelta packet_for_rdata packets_for_certs parents stdio tags toposort cat cert checkout comment chkeypass complete cvs_import db (all) disapprove dropkey explicit_merge (*) fdiff fload fmerge genkey heads help identify list certs/keys/branches/epochs/tags/vars merge (*) merge_into_dir (*) privkey propagate (*) pubkey pull push rcs_import read serve setup set show_conflicts (*?) sync tag testresult trusted unset