Re: [darcs-users] preparing a 2.14 release

2018-02-07 Thread Ben Franksen
Am 08.02.2018 um 00:22 schrieb Guillaume Hoffmann: > Ganesh has published some unscreened changes at > http://bugs.darcs.net/patch1628 but said today on IRC that the windows > issues still require work. I was planning to take a closer look at these changes. > Maybe do you have a powerful enough

[darcs-users] referencing in-repo branches

2018-03-07 Thread Ben Franksen
Hi All the recent discussions here gave me a much better picture of what kind of features we should strive for when we add in-repo branches. But perhaps I should not (yet) talk about branches. Let us talk instead about "patch sequences". The way Darcs works today is that it knows of exactly one

Re: [darcs-users] referencing in-repo branches

2018-03-07 Thread Ben Franksen
Am 07.03.2018 um 22:10 schrieb Wolfgang Jeltsch: > Am Mittwoch, den 07.03.2018, 19:11 +0100 schrieb Ben Franksen: >> [...] > > This sounds just great. I would love to see this implemented. > > Please keep up the good work! Hi Wolfgang Thanks for the encou

Re: [darcs-users] so long and thanks for all the darcs

2018-03-07 Thread Ben Franksen
nded up having to work through a lot of > stuff to figure out what I think about the various VCSes, and record > it here for those interested in understanding why git seems so wrong- > headed to many users, and yet persists in its idiosyncratic ways. I'm > sure there will be many points of disa

Re: [darcs-users] post 2.14.0 tasks / decisions

2018-04-14 Thread Ben Franksen
Am 13.04.2018 um 23:03 schrieb Guillaume Hoffmann: > * decide if include DarcsDen as part of Darcs' repository to avoid bitrot A bold move. I understand the motivation but I am not comfortable with the idea of adding external and to a large extent completely unrelated code to Darcs. I think with

Re: [darcs-users] so long and thanks for all the darcs

2018-04-17 Thread Ben Franksen
Am 13.04.2018 um 10:19 schrieb Stephen J. Turnbull: > Benjamin Franksen writes: > > On 04/10/2018 08:34 AM, Stephen J. Turnbull wrote: > > > > Any user who understands what a ref is will say "a Darcs tag is > > > too a ref!" I think. > > > > Perhaps (but you won't, right?). > > I would, in

Re: [darcs-users] preparing a 2.14 release

2018-03-28 Thread Ben Franksen
Am 26.03.2018 um 17:38 schrieb Guillaume Hoffmann: >> IMO the two rebase bugs I stumbled over (http://bugs.darcs.net/issue2581 >> and http://bugs.darcs.net/issue2575) must be fixed before a release. > > That would be great. I have fixed them both, ha! > I am thinking about releasing 2.14.0 on

Re: [darcs-users] so long and thanks for all the darcs

2018-03-29 Thread Ben Franksen
Am 29.03.2018 um 10:08 schrieb Stephen J. Turnbull: > Ben Franksen writes: > > If yes, then I begin to understand why as a Darcs user I found it so > > difficult to become familiar with git. Because this concept of a "ref" > > has no (user visible) counterpart in

Re: [darcs-users] so long and thanks for all the darcs

2018-03-20 Thread Ben Franksen
Am 20.03.2018 um 10:33 schrieb Stephen J. Turnbull: > Ben Franksen writes: > > Am 19.03.2018 um 09:12 schrieb Stephen J. Turnbull: > > But git chooses to not clone all the refs by default and there is a > > reason for that because it would have to pull all the referen

Re: [darcs-users] Resurrecting a file?

2018-03-24 Thread Ben Franksen
Am 22.03.2018 um 11:13 schrieb Stephane Bortzmeyer: > I am wondering if there is a simply way to ressurect a file which has > been deleted some times ago. Today, I do a darcs changes (if I > remember the file name) or a darcs test (if I don't), find the last > patch where the file existed, then do

Re: [darcs-users] so long and thanks for all the darcs

2018-03-24 Thread Ben Franksen
Hi Steve sorry for (again) responding at length. You gave me yet more ideas... Am 22.03.2018 um 01:15 schrieb Stephen J. Turnbull: > Ben Franksen writes: >> My experience with git tells me that when I make a clone what I get >> is /not/ identical to upstream. > > I may

Re: [darcs-users] String encoding issue

2018-03-24 Thread Ben Franksen
Am 22.03.2018 um 12:40 schrieb Stephane Bortzmeyer: > On Thu, Mar 22, 2018 at 11:29:54AM +, > Eric Kow wrote > a message of 157 lines which said: > >> Does setting DARCS_DONT_ESCAPE_8BIT to 1 help? > > Ah yes, thanks. I then discovered >

Re: [darcs-users] so long and thanks for all the darcs

2018-03-04 Thread Ben Franksen
Am 04.03.2018 um 05:03 schrieb Karl O. Pinc: > On Sat, 3 Mar 2018 18:36:32 -0800 > Evan Laforge wrote: > >> On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc wrote: >>> This being so, I'm curious why a darcs user would choose >>> git over mercurial. >> >>

Re: [darcs-users] so long and thanks for all the darcs

2018-03-04 Thread Ben Franksen
Am 04.03.2018 um 21:12 schrieb Karl O. Pinc: > On Sun, 4 Mar 2018 12:04:01 +0100 > Stephane Bortzmeyer wrote: > >> * no branches. Don't add them! The one-branch-per-repo model is much >> better > > Thinking out loud here. > > If I had to vote today I'd say: > > -1 on

Re: [darcs-users] so long and thanks for all the darcs

2018-03-05 Thread Ben Franksen
Am 05.03.2018 um 03:40 schrieb Evan Laforge: > On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen <ben.frank...@online.de> wrote: >>> There are a few other quibbles, like how obliterate -O is too slow to >>> be useful, >> >> (perhaps we should have made --no-minim

Re: [darcs-users] so long and thanks for all the darcs

2018-03-05 Thread Ben Franksen
Am 05.03.2018 um 01:47 schrieb Karl O. Pinc: > On Sun, 4 Mar 2018 23:23:33 +0100 > Ben Franksen <ben.frank...@online.de> wrote: > >> What made me re-consider >> the idea was that I found I like the way mercurial automatically >> creates a branch

Re: [darcs-users] so long and thanks for all the darcs

2018-03-05 Thread Ben Franksen
Am 05.03.2018 um 10:19 schrieb Ben Franksen: > Am 05.03.2018 um 03:40 schrieb Evan Laforge: >> Record changes in darcs 2.12.5, then say yes to "add a long comment" >> where EDITOR=vim. Now ^Z out of vim, and then fg back. At that >> point, vim is in command

[darcs-users] removing --reply option from darcs

2018-10-13 Thread Ben Franksen
I am sending this to the users list to see if anyone is actually relying this feature because I would like to remove it. Darcs has since its early days supported a --reply option for the apply command. I think this feature has been meant for continuous integration. So when someone sends a patch,

Re: [darcs-users] removing --reply option from darcs

2018-11-07 Thread Ben Franksen
more maintainable! > > Guillaume > > El sáb., 13 de oct. de 2018 a la(s) 17:11, Ben Franksen ( > ben.frank...@online.de) escribió: > >> I am sending this to the users list to see if anyone is actually relying >> this feature because I would like to remove it

Re: [darcs-users] force commuting in practice

2019-06-16 Thread Ben Franksen
anges. And on unsuspend of B;A it tells me there are conflicts but there are no conflict markups. For the test if used > darcs log -v patch f41bf21d0d6027ff8f9de1dbb3b6b64b098c953c Author: Ben Franksen Date: Sun Jun 16 14:15:25 CEST 2019 * bar hunk ./f 1 -foo +bar patch 16f117520aac3b17

Re: [darcs-users] rebase pull/apply vs. pull/apply --rebase

2020-02-03 Thread Ben Franksen
Am 02.02.20 um 19:11 schrieb Ganesh Sittampalam: > On 28/01/2020 10:37, Ben Franksen wrote: >> It would be quite convenient to have a --rebase option for obliterate >> that automatically suspends all patches that depend on the one(s) you >> want to obliterate. > >&g

[darcs-users] rebase pull/apply vs. pull/apply --rebase

2020-01-28 Thread Ben Franksen
I have been thinking again about the UI design question for rebase: subcommand vs. option. What prompted me was the following scenario, which I encountered just now: Suppose you want to obliterate patch A. Perhaps it turned out that A wasn't such a good idea after all. But you also have another

[darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-19 Thread Ben Franksen
Note this patch is for branch-2.14, it will probably not apply cleanly to screened. I propose we pull it anyway and resolve the conflicts. 1 patch for repository http://darcs.net/releases/branch-2.14: patch 7f9e8d76769e21fde94395a06d2b2a99cb57b5dc Author: Ben Franksen Date: Wed Feb 19 09:45

Re: [darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-20 Thread Ben Franksen
I have fixed the email setting to patc...@darcs.net. Am 19.02.20 um 10:33 schrieb Ben Franksen: > It seems branch-2.14 has a wrong email setting. pEpkey.asc Description: application/pgp-keys ___ darcs-users mailing list darcs-users@osuosl.org ht

Re: [darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-19 Thread Ben Franksen
It seems branch-2.14 has a wrong email setting. This should have gone to the tracker, possibly via darcs-devel? Am 19.02.20 um 09:52 schrieb Ben Franksen: > Note this patch is for branch-2.14, it will probably not apply cleanly to > screened. I propose we pull it anyway and resolve the con

Re: [darcs-users] Darcs-Subversion bridge

2020-03-12 Thread Ben Franksen
Hi Henning Am 11.03.20 um 12:37 schrieb Henning Thielemann: > I want to contribute to a Subversion repository, but I want to edit > changes and run tests before committing, because in Subversion you can > hardly revert a commit. I have seen there were some ideas to bridge > Darcs to Subversion.

Re: [darcs-users] Learning darcs

2020-05-05 Thread Ben Franksen
Hi Tom Am 23.04.20 um 08:49 schrieb Tom Midgley: > In the learning material about darcs on http://darcs.net/Using/HunkEditor > there > is an example which used to be at > > |http://patch-tag.com/r/kowey/rambling-robot| > > which now a site about testosterone patches for ageing bikers > It

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-25 Thread Ben Franksen
Am 25.06.20 um 18:52 schrieb James Cook: > I'm trying to learn more about how darcs force commutes work. There is a reason we do not have such a command ;-) > What I'd like to do is create a repository R1 with patches A and B, > and then look at the patches that result if A and B get >

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-26 Thread Ben Franksen
Am 26.06.20 um 05:03 schrieb James Cook: >>> What I'd like to do is create a repository R1 with patches A and B, >>> and then look at the patches that result if A and B get >>> force-commuted. >>> >>> E.g. if I could pull just patch B and not A to a new repository, I >>> think that would do the

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-27 Thread Ben Franksen
Am 26.06.20 um 20:55 schrieb James Cook: >>> I've been reading about patch theory [0]. I *thought* what's supposed >>> to happen is this: >>> >>> * The effect of B' is the same as the effect of A. (i.e. create the file) >>> * The effect of A' is the same as the effect of B. (i.e. add "some text")

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 03:54 schrieb James Cook: > I'm glad to hear about darcs-3. I was worried work on implementing > Camp had stopped completely. Yes, I am quite happy about that, too. It means we finally have an implementation of a patch theory that satisfies all required patch laws. We have upgraded

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 12:53 schrieb James Cook: >> Converting existing repos to darcs-3 is unfortunately one of the things >> we havent't done yet. I have implemented a number of conversion schemes >> but they all fail in some situations. There are two hard problems to >> solve here: >> >> (1) What to do

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 16:51 schrieb James Cook: >> There is also more than just hunks. What about file renames? A file >> rename commutes with a hunk that changes the file, and in darcs this >> changes the hunk patch to refer to the renamed file. You need to change >> the internal representation to refer

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 13:46 schrieb James Cook: >> This in turn led me to the more general question of how to detect >> inconsistencies when exchanging patches between repos. The problem here >> is that darcs currently relies on global uniqueness properties that are >> quite easy to invalidate (e.g. by

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > Example: Suppose a is the starting context (empty repository), Q1 > creates the file "foo" starting from a, Q2 creates the file "bar" > starting from there, and b and c are the contexts after P1 and then P2. > The address (a, c, [Q1, Q2], {}, {1, 2})

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
I haven't fully digested everything you wrote but I guess a remark may be in order, lest you waste time on something that cannot be implemented efficiently. I am not claiming this is equivalent to what you aim at, but I think it is at least related. A well-known and quite natural way to identify

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > The context address /points to/ a context c if there exists a > permutation of (Qi) such that all the patches with names in X come > before patches with names in Y, and c is the after-context of the k-th > patch in the sequence (equivalently, the

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-30 Thread Ben Franksen
Am 29.06.20 um 19:12 schrieb James Cook: >> Another problem is that even supposing commutation does not change prim >> patches, in darcs you still have conflictors. And conflictors >> /definitely/ have to change representation when we commute them: the >> merge-commute law obviously requires that.

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 17:13 schrieb James Cook: > On Wed, 1 Jul 2020 at 10:21, Ben Franksen wrote: >> Am 01.07.20 um 05:09 schrieb James Cook: >>> The context address /points to/ a context c if there exists a >>> permutation of (Qi) such that all the patches with names i

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 17:59 schrieb Ben Franksen: > Am 01.07.20 um 17:13 schrieb James Cook: >> On Wed, 1 Jul 2020 at 10:21, Ben Franksen wrote: >>> Am 01.07.20 um 05:09 schrieb James Cook: >>>> The context address /points to/ a context c if there exists a >>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
The final chapter about the effect of extended patches and how to resolve the conflicts they represent could use a bit of elaboration. For instance, though you refer to the process, you haven't explained how (extended) patches are merged. I think you will need to introduce inversion for this. This

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 18:39 schrieb James Cook: >> A well-known and quite natural way to identify the equivalence class of >> all patches that a given patch P can be commuted to, is to use the so >> called "minimal context". A minimal context C(P) for some patch P is a >> sequence of patches starting at

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
> Definition: A context address (a, b, (Qi), X, Y) is a /simplification/ > of a context address (a', b', (Q'i), X', Y') if X and Y are subsets of > (or equal to) X' and Y' and the sequence (Q'i) can be permuted so that > it first follows the patches in X' \ X from a' to a, then follows the >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 18:45 schrieb James Cook: >> Just to check I understood the idea (up to this point): roughly >> speaking, you represent "unrepresentable" states by formally commuting >> patches. >> >> That is, if we regard the primitive states as vertices and primitive >> (named) patches as edges

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 05.07.20 um 20:36 schrieb Ben Franksen: > Am 04.07.20 um 23:59 schrieb James Cook: >>> I think that whenever a sequence of patches starts and ends at a >>> primitive context (e.g. this is true of an unconflicted repository) >>> you can re-order the patches

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 22:22 schrieb James Cook: >>> But yes, I realized after writing it that I never covered inverting >>> extended patches. >>> >>> Thinking about it more, I think I've found some problems. Let's say s >>> is the starting context of A and B, and A ends with a and B ends with >>> B. Here

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Am 04.07.20 um 00:10 schrieb James Cook: >>> I'd say this is a feature, not a bug. If you mark the conflict between A >>> and B as resolved, *without* recording a new patch, then this means you >>> are satisfied with the resolution that reverts both changes. There is no >>> reason why pulling C

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 23:44 schrieb Ben Franksen: > Am 03.07.20 um 22:22 schrieb James Cook: >> I think I've found a new problem with Proposition 5, though. >> >> Suppose A, B and C are three mutually conflicting patches with >> starting context s. >> >> Suppose I

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-07 Thread Ben Franksen
Definition: A category X is said to be an inverse category whenever, for each arrow f : A -> B in X, there exists a unique f^ : B -> A in X such that ff^f = f and f^ff^ = f^. (I write composition as juxtaposition without an operator.) Given a universe of extended invertible patches, define a

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Hi James It was an interesting journey through the sea of patches! I think your construction is sound. I have somewhat skimmed over the more complicated proofs, but I trust they contain no grave mistakes, given that your exposition is otherwise very careful and precise. > Remark: In other

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Am 01.07.20 um 18:45 schrieb James Cook: >> Just to check I understood the idea (up to this point): roughly >> speaking, you represent "unrepresentable" states by formally commuting >> patches. >> >> That is, if we regard the primitive states as vertices and primitive >> (named) patches as edges

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 05:22 schrieb James Cook: > On Thu, 2 Jul 2020 at 18:40, Ben Franksen > wrote:> The final chapter about the effect of extended patches and how > to >> resolve the conflicts they represent could use a bit of elaboration. For >> instance, though you refer to

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 02.07.20 um 00:29 schrieb James Cook: > Definition: A /patch address/ is a patch sequence address where the > sequence (nj) has length one. > > Sorry, there are a lot of definitions, but maybe you missed that one? Oops. Yes, sorry. I was jumping around, trying to get a grip on the idea. >>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 02.07.20 um 00:37 schrieb James Cook: >> The construction works by inductively taking any pair of incommutable >> patches (in sequence, i.e. with a common middle state) and then >> "formally" commuting it. The new node is represented as that pair of >> patches. Is that, essentially, the idea? >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > Definition: We associate a primitive context to every context address > (and in particular to every extended context) (a, b, (Qi), X, Y) using > the following recursive algorithm. > > * If X=Y={}, then the context is a (=b). This is an embedded primitive

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
> Definition: Let A=(a, b, (Qi), (nj), X, Y) be an patch sequence address > of length n (i.e. (nj) has n names in it). The /separation/ of A is a > sequence of n extended patches. Patch j in the sequence is the minimal > form of (a, b, (Qi), nj, X U {before}, Y U {after}), where {before} is > the

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > The overall procedure is this: > > 1. Merge the individual patches to be permuted into a patch sequence > address (a, b, (Qi), (nj), X, Y). (You could merge a pair of adjacent > patches, the whole sequence of patches in the repo, or anything in >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
> Definition: A /patch sequence address/ is a tuple > (a, b, (Qi), (nj), X, Y), where a and b are (primitive) contexts, (Qi) > is a sequence of (primitive) patches going from a to b, nj is a sequence > of unique names of patches in (Qi), and X and Y are a partition of the > remaining names in

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-05 Thread Ben Franksen
Am 04.07.20 um 23:59 schrieb James Cook: >> I think that whenever a sequence of patches starts and ends at a >> primitive context (e.g. this is true of an unconflicted repository) >> you can re-order the patches so that they are all primitive. > > I should add: this probably requires allowing new

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-05 Thread Ben Franksen
Am 04.07.20 um 23:43 schrieb James Cook: > On Sat, 4 Jul 2020 at 09:59, Ben Franksen wrote: >> Am 04.07.20 um 00:10 schrieb James Cook: >>>>> I'd say this is a feature, not a bug. If you mark the conflict between A >>>>> and B as resolved, *without* rec

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 06.07.20 um 19:37 schrieb James Cook: > On Mon, 6 Jul 2020 at 10:29, Ben Franksen wrote: >> Am 05.07.20 um 20:36 schrieb Ben Franksen: >>> Am 04.07.20 um 23:59 schrieb James Cook: >>>>> I think that whenever a sequence of patches starts and ends at a >>&

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 06.07.20 um 19:33 schrieb James Cook: >> I guess you want to avoid proper cycles, i.e. cycles other than those of >> the form patches;patches^, but that's just an intuition. > > A;A^;B;B^;C;C^ isn't a proper cycle in that sense but may be useful to > be able to have if you're merging or have