Patch 1740 bugfix in identifyRepositoryFor

Title bugfix in identifyRepositoryFor
Superseder Nosy List bf
Related Issues
Status accepted Assigned To

Created on 2018-10-03.18:43:54 by bf, last changed 2018-11-18.23:27:46 by bf.

File name Status Uploaded Type Edit Remove
bugfix-in-identifyrepositoryfor.dpatch bf, 2018-10-03.18:43:53 application/x-darcs-patch
patch-preview.txt bf, 2018-10-03.18:43:53 text/x-darcs-patch
unnamed bf, 2018-10-03.18:43:53 text/plain
See mailing list archives for discussion on individual patches.
msg20361 (view) Author: bf Date: 2018-10-03.18:43:53
The bug is not critical since we currently don't have any formats
that we can read but not write (or vice versa).

1 patch for repository http://darcs.net/screened:

patch d16454aed52d9e7670fc98585c67088c49dc74c8
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Sep 30 19:03:16 CEST 2018
  * bugfix in identifyRepositoryFor
  The problem may be due to a misunderstanding on my part when I refactored
  this code for the first time. The first parameter is not necessarily teh
  source and the second not necessarily the target. In fact, these roles are
  different for e.g. push and pull. Instead, the first is the local repo and
  the second is the remote one. To call transferProblem correctly requires
  that we know whether we are going to read or write so we pass that as an
  additional argument.
msg20411 (view) Author: ganesh Date: 2018-10-17.06:38:48
When was the first refactoring you're referring to? The only one I
could find was "make type Repository abstract" from a year ago that
didn't seem to affect this code.

I looked back a little way (to 2.12) and the logic always seems to 
have been to look at 'transferProblem target source'.
msg20413 (view) Author: bf Date: 2018-10-17.08:24:46
I guess I meant this one:

patch e76075aeacf09a0b6620c58b2e902cf6b2a2f7b0
Author: Ben Franksen <benjamin.franksen@helmholtz-berlin.de>
Date:   Sat Feb 14 02:56:31 CET 2015
  * cleanup: Repository.Format and .Internal haddocks and variable 
  Also rename readfromAndWritetoProblem to transferProblem.

But I see now that it only clarifies which repo is which by naming 
them source/target and does not change semantics. So you are right 
and this bug was there to begin with.
msg20469 (view) Author: ganesh Date: 2018-11-16.12:43:25
This patch turns out to break the 'rebase-remote' test if applied 
without the rebase refactoring (patch1731).
msg20524 (view) Author: bf Date: 2018-11-18.23:27:46
Are you sure that this patch:

"adapt rebase tests to new style of storing rebase patch"

is not applied? It probably misses an explicit dependency on the 
rebase changes.
Date User Action Args
2018-10-03 18:43:54bfcreate
2018-10-04 08:00:57ganeshsetstatus: needs-screening -> needs-review
2018-10-17 06:38:49ganeshsetmessages: + msg20411
2018-10-17 06:38:53ganeshsetstatus: needs-review -> review-in-progress
2018-10-17 08:24:46bfsetmessages: + msg20413
2018-11-16 09:04:17ganeshsetstatus: review-in-progress -> accepted-pending-tests
2018-11-16 12:43:26ganeshsetmessages: + msg20469
2018-11-17 15:45:47ganeshsetstatus: accepted-pending-tests -> accepted
2018-11-18 23:27:46bfsetmessages: + msg20524