darcs

Patch 1862 resolve issue2550: apply only properly m... (and 2 more)

Title resolve issue2550: apply only properly m... (and 2 more)
Superseder Nosy List bf
Related Issues
Status accepted Assigned To
Milestone

Created on 2019-07-29.21:26:14 by bf, last changed 2019-08-31.14:14:19 by ganesh.

Files
File name Status Uploaded Type Edit Remove
patch-preview.txt bf, 2019-07-29.21:26:14 text/x-darcs-patch
patch-preview.txt bf, 2019-08-08.23:10:13 text/x-darcs-patch
resolve-issue2550_-apply-only-properly-mangled-resolutions_-warn-about-any-others.dpatch bf, 2019-07-29.21:26:14 application/x-darcs-patch
resolve-issue2550_-apply-only-properly-mangled-resolutions_-warn-about-any-others.dpatch bf, 2019-08-08.23:10:13 application/x-darcs-patch
unnamed bf, 2019-07-29.21:26:14 text/plain
unnamed bf, 2019-08-08.23:10:13 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg21020 (view) Author: bf Date: 2019-07-29.21:26:14
I won't screened this immediately, as this is a noticeable (and
incompatible) change in the UI.

3 patches for repository http://darcs.net/screened:

patch 6b11cedb1dde629063fc9b21894246734427c67c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:34:44 CEST 2019
  * resolve issue2550: apply only properly mangled resolutions, warn about any others
  
  To support this change we add the new data type StandardResolution and
  return that from standardResolution. It contains a summary of the data we
  gathered from calling resolveConflicts: the mangled resolutions, merged into
  a single FL, the list of conflicted paths, and an IO action to warn about
  and display any (unravelled) conflicts that we couldn't properly mangle. The
  warning is normally only displayed if we actually want mangling to happen
  i.e. if --mark-conflicts is in effect (except for the mark-conflicts command).

patch ad4467371a96a87438930605e741620f99501001
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:20:52 CEST 2019
  * tests: adapt conflict-doppleganger.sh
  
  A conflict involving 'addfile' prims cannot be cleanly mangled. This means
  that there is nothing to record after the pull and the test therefore fails.
  But this isn't what we want to test, so we record the 'addfile' separately
  and share it.

patch b57365b1d1990d5493086608ef466841e81c4b8f
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:46:45 CEST 2019
  * move announceConflicts from D.R.Merge to D.R.Resolution
Attachments
msg21048 (view) Author: ganesh Date: 2019-08-06.21:36:41
I think the principle is fine, and we need to go in this direction.

I think we should defer the construction of the IO action to the UI
layer. Anything other than the command-line tool will want to 
present the results in a different way and certainly won't want to 
call ePutDocLn.
msg21053 (view) Author: bf Date: 2019-08-08.17:12:24
> I think we should defer the construction of the IO action to the UI
> layer. Anything other than the command-line tool will want to 
> present the results in a different way and certainly won't want to 
> call ePutDocLn.

Right. Will fix.
msg21054 (view) Author: bf Date: 2019-08-08.22:25:40
>> I think we should defer the construction of the IO action to the UI
>> layer. Anything other than the command-line tool will want to 
>> present the results in a different way and certainly won't want to 
>> call ePutDocLn.

Should we return all the raw unravelled conflicts or just those we
couldn't properly mangle?
msg21056 (view) Author: ganesh Date: 2019-08-08.22:39:10
On 08/08/2019 23:25, Ben Franksen wrote:
> 
> Ben Franksen <ben.franksen@online.de> added the comment:
> 
>>> I think we should defer the construction of the IO action to the UI
>>> layer. Anything other than the command-line tool will want to 
>>> present the results in a different way and certainly won't want to 
>>> call ePutDocLn.
> 
> Should we return all the raw unravelled conflicts or just those we
> couldn't properly mangle?

I guess either return all the raw unravelled conflicts and let the
caller handle mangling what it can and reporting on the rest, or return
the mangled ones + the raw unravelled ones we can't mangle.
msg21057 (view) Author: bf Date: 2019-08-08.23:10:13
> I guess either return all the raw unravelled conflicts and let the
> caller handle mangling what it can and reporting on the rest, or return
> the mangled ones + the raw unravelled ones we can't mangle.

The latter, then. Here we go.

BTW, only the last patch is new, the rest is dependencies.

3 patches for repository http://darcs.net/screened:

patch 6b11cedb1dde629063fc9b21894246734427c67c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:34:44 CEST 2019
  * resolve issue2550: apply only properly mangled resolutions, warn about any others
  
  To support this change we add the new data type StandardResolution and
  return that from standardResolution. It contains a summary of the data we
  gathered from calling resolveConflicts: the mangled resolutions, merged into
  a single FL, the list of conflicted paths, and an IO action to warn about
  and display any (unravelled) conflicts that we couldn't properly mangle. The
  warning is normally only displayed if we actually want mangling to happen
  i.e. if --mark-conflicts is in effect (except for the mark-conflicts command).

patch b57365b1d1990d5493086608ef466841e81c4b8f
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:46:45 CEST 2019
  * move announceConflicts from D.R.Merge to D.R.Resolution

patch 09bbd7ae6fe2ae2cee8a2e64ce975438a02d1bdd
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri Aug  9 01:04:08 CEST 2019
  * store the raw unmangled parts of a conflict in StandardResolution
  
  This allows client code to display them in any form they wish, not
  necessarily using ePutDocLn. We do provide warnUnmangled as a convenience
  function, but also showUnmangled and even more low-level showUnravelled.
Attachments
msg21284 (view) Author: ganesh Date: 2019-08-30.20:01:37
>   * resolve issue2550: apply only properly mangled resolutions, warn about any others

Would a test make sense for this new behaviour?

> data StandardResolution prim wX =

This would benefit from some haddocks. Not critical though, it's not too
hard to figure out what's what.

Otherwise fine. Above things are optional so I'll mark this as accepted now.

>   * move announceConflicts from D.R.Merge to D.R.Resolution
>   * store the raw unmangled parts of a conflict in StandardResolution

Fine
History
Date User Action Args
2019-07-29 21:26:14bfcreate
2019-08-06 21:36:41ganeshsetmessages: + msg21048
2019-08-08 17:12:24bfsetmessages: + msg21053
2019-08-08 22:25:40bfsetmessages: + msg21054
2019-08-08 22:39:10ganeshsetmessages: + msg21056
2019-08-08 23:10:14bfsetfiles: + patch-preview.txt, resolve-issue2550_-apply-only-properly-mangled-resolutions_-warn-about-any-others.dpatch, unnamed
messages: + msg21057
2019-08-12 14:33:08bfsetstatus: needs-screening -> needs-review
2019-08-30 20:01:37ganeshsetmessages: + msg21284
2019-08-30 20:01:44ganeshsetstatus: needs-review -> accepted-pending-tests
2019-08-31 14:14:19ganeshsetstatus: accepted-pending-tests -> accepted