notes/meetings/berlin-16-minutes

The Berlin '16 hackathon was held at the elego offices in Berlin, Germany
on October 10-14.

Tree conflict resolution
------------------------

Stefan Sperling notes that there are several things about the tree conflict
resolver that are either missing or require further work:

  (Points with [X] were marked as important on the blackboard.)

1. Recommended resolution option(s)

  Having a reasonable default option may be useful for the users, so that
  they wouldn't be continuously prompted on how to resolve the conflicts
  (--accept=recommended).  Another use case is the automatic conflict
  resolution in a non-interactive environment (buildbot).

  Ivan Zhakov asked whether it makes sense to automatically apply the
  "recommended" resolution option in case if there's only one "real" option.

2. Improving the move detection heuristic

  There are known cases where the current move detection heuristic doesn't
  work.  One example would be "cp A B; mv B/foo C/foo".

  ###  What are the known and important cases that we need to handle?

3. Updating incoming moves is not implemented for directories [X]

  ###

  During the discussion of this point, Ivan Zhakov asked if it's possible to
  extend the tree conflict storage so that all the necessary data would be
  available to the resolver, and so that it wouldn't have to contact the
  server during the actual resolution.

4. Incoming add resolution for directories

  There is ongoing work by Stefan Sperling on the "resolve-incoming-add"
  branch that is aimed to properly handle cases with added directories by
  using the diff processor.

5. Working copy operations are not atomic

  The problem is that performing things non-atomically may cause problems, for
  instance, if the resolution process is cancelled by the user.

  Bert Huijben pointed out that the same problem exists if you run a merge.

6. Markup for descriptions, titles, short descriptions for third-party
   API users [X]

  The issue was initially brought up by Ivan Zhakov.  There are a few minor
  problems with using the new API in 3rd-party applications -- for instance,
  currently they may need to somehow deal with the newlines, strip out and
  transform URLs, etc.  They could benefit from having the details exposed
  with some kind of a markup (that would separate URLs, ...).  This could
  give the API users more flexibility when displaying the conflict details
  and options.

  Another related topic is that currently the API does not expose the
  localized option titles (like, "Move my file and merge"), and does not
  expose the short description ("Remote move vs local edit") of the conflict.

7. New resolution options

  We might need a mechanism to add new resolution options in patch releases.
  Otherwise, new resolution options will only become available to the users
  with the next minor release.

8. Resolution scripts

  ###

9. More tests [X]

  Currently, we do not test the behavior of interactive conflict resolver
  in the Python tests, just via the C tests for the API.

  One minor discussed thing was that we could benefit from just using the
  "trunk/branches/tags" layout in the new tests, instead of using the Greek
  tree.

10. Issue with multirange merges

  It was pointed out that the switch to the new conflict resolution API
  might have broken one scenario.  In Subversion 1.9, if a user performs a
  multirange merge, and merging the first revision range produces conflicts,
  then resolving every conflict would automatically continue the merge.
  In trunk, a user would have to manually re-run the merge command.

  It was mentioned that this could be caused by putting the client in charge
  of the conflict resolution, instead of having a callback-based mechanism.

11. Using the new API requires users of the existing conflict API to
    completely rewrite the relevant parts of the code

  (Items 10 and 11 were discussed together, but are split for convenience.)

  Another potential issue with making the API user responsible for properly
  resolving the conflicts when it should be done, is that users of the
  existing conflict API would need to rewrite their code to benefit from
  the new resolution options.  And they might need to update the code that
  handles every operation.