Re: [darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread James Cook
On Fri, 25 Sep 2020 at 10:48, Ben Franksen wrote: > Hi Everyone > > I am thinking about changing the behavior and/or available options for > hijacking patches. > > Context: When working from home I have two identities in my > ~/.darcs/author file: one with my work email address and one with my >

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

2020-09-16 Thread James Cook
> So this can succeed only if c does not conflict with either of its > sibling cancelled branches, that is, if c^ commutes with all sequences > ("paths") in the cancelled branches, that is, all elements of {d, e;f, > e;g, e;h;i}. We then get > > a--b'-c' > |\ >d' e'-f' >

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

2020-09-09 Thread James Cook
> > Oops, I didn't pay enough attention to your concrete example. > > > > Did you mean b = hunk f 1 [1a,2,3] [1b,2b,3b]? (I'm guessing hunk f n > > [u,v,w] [x,y,z] means lines n..n+2 of file f start out as [u,v,w] and > > end up as [x,y,z]; is that right?) > > Yes to both, sorry I messed up the

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

2020-09-08 Thread James Cook
> >> In your case, for two adjacent /sequences/ A;B, and equivalences A~A', > >> B~B', we need to have that A;B commutes iff A';B' commutes. Now, suppose > >> you have patches a;b;b^;c, where none of the adjacent pairs commute. > >> You'd have to show that this implies that a;c commutes neither

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

2020-09-08 Thread James Cook
On Thu, 3 Sep 2020 at 14:24, Ben Franksen wrote: > > >>> If I wanted to implement it, I think it would just become this: > >>> > >>> * A repository consists of two things: > >>> * A sequence S of primitive patches with distinct names, starting at > >>> O, with no inverses (i.e. only positive

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

2020-09-01 Thread James Cook
> One a minor note, your patch universe definition is not suitable for > extended patches as defined in Darcs: For these, the square commute law > (which you call rotation, perhaps a better name) does not hold. Though > to be fair, a while ago we have stopped treating them as invertible in > the

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

2020-09-01 Thread James Cook
On Wed, 19 Aug 2020 at 11:52, Ben Franksen wrote: > Am 19.08.20 um 11:44 schrieb Ben Franksen: > > The fact that your patches have no "content" is of of course a result of > > starting out with "enriched" contexts. As you note in 2.2 > > Interpretation, your contexts can *not* in general be

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

2020-08-18 Thread James Cook
> I changed the definition of Context > Address to work better with my new "patch universe" definition, but I > think it amounts to the same thing. Thinking about it more, I'm not sure my new definition of Context Address is a good one, since I've been finding it hard to associate a primitive

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

2020-08-18 Thread James Cook
> >> A good way to see if your definition holds up is to see whether you can > >> prove your > >> > >> Conjecture 1: Every context address points to at most one context. > > > > Sure, that's a nice goal. > > > > I think I will start a latex file, try to define what a patch theory > > is and what

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

2020-08-13 Thread James Cook
Question: is there a good place to read about how "darcs pull" works? You mentioned hashed inventories in an earlier email; I guess I could look at the darcs source keeping that in mind. (I've been thinking about reading some of the source code anyway). It's relevant to the last part of this

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

2020-08-08 Thread James Cook
> > and whether it's okay to restrict S to be tree-like during the > > intermediate steps. It is probably simpler to just drop the cycle > > version and think only of trees, but I want to make sure I understand > > how the primitive patch theory's commuting rules turn into tree > >

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

2020-07-06 Thread 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 > >>> primitive context (e.g. this is true of an uncon

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

2020-07-06 Thread James Cook
> > I don't know how darcs figures out what patches need to be pulled, > > especially if R1 is lazy. > > Don't let yourself be confused by lazy repos. > > Conceptually, darcs reads the complete remote repo, figures out the > common patches, commutes all uncommon patches in both repos to the end, >

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

2020-07-05 Thread James Cook
Hi darcs-users, I'm trying to learn more about how darcs force commutes work. 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

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

2020-07-04 Thread 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 permutations that weren't in the primitive

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

2020-07-04 Thread James Cook
On Sat, 4 Jul 2020 at 16:05, Ben Franksen wrote: > 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

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

2020-07-04 Thread 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* recording a new patch, then this means you > >>

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

2020-07-03 Thread 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 should conflict now. If, on the other hand,

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

2020-07-03 Thread 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 are three problems: > > > > (a) I'm not

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

2020-07-02 Thread 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 the process, you haven't explained how > (extended) patches are merged. I

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

2020-07-02 Thread James Cook
On Thu, 2 Jul 2020 at 09:42, Ben Franksen wrote: > 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 algori

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

2020-07-02 Thread James Cook
On Thu, 2 Jul 2020 at 09:12, Ben Franksen wrote: > 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 p

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

2020-07-02 Thread James Cook
On Thu, 2 Jul 2020 at 08:57, Ben Franksen wrote: > > 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,

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

2020-07-02 Thread James Cook
On Thu, 2 Jul 2020 at 08:32, Ben Franksen wrote: > > 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),

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

2020-07-02 Thread James Cook
On Thu, 2 Jul 2020 at 07:53, Ben Franksen wrote: > 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" c

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

2020-07-02 Thread James Cook
> Thanks for writing this down. I think you should add this example to > your text as it is a good illustration. Good idea; done at https://hub.darcs.net/falsifian/misc-pub/patch/5571a2e0c22659114fd5a919e06be844819afccc . James ___ darcs-users mailing

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

2020-07-01 Thread 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? Sorry, I should add one note here: I'm not

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

2020-07-01 Thread James Cook
On Wed, 1 Jul 2020 at 21:14, Ben Franksen wrote: > 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. >

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

2020-07-01 Thread James Cook
> BTW, you don't say it explicitly, but since in several places you refer > to names, I was assuming that in your theory prim patches are always named. Yes, I'm assuming every prim patch has a unique name. Part of the tuple encoding an extended patch is the name of a prim patch. That could be

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

2020-07-01 Thread 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 in a graph, then you extend the graph with new >

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

2020-07-01 Thread 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 the empty state and preceding P, and > that

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

2020-07-01 Thread James Cook
On Wed, 1 Jul 2020 at 10:12, Ben Franksen wrote: > 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

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

2020-07-01 Thread 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 in X come > > before patches with names in Y, and c

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

2020-07-01 Thread James Cook
On Wed, 1 Jul 2020 at 09:44, Ben Franksen wrote: > 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 the

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

2020-06-30 Thread James Cook
== Prologue == This is a story about how to extend a patch theory into one where any sequence of patches can be permuted into any other order. In particular, this means every merge is a clean merge in the new theory. One small catch: after a conflict, it's not possible to continue applying

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

2020-06-29 Thread James Cook
> It had never occurred to me to think of that as a possible solution. > Sometimes it helps to get input from someone who is not as deeply > involved and who can come up with fresh ideas. Many thanks for sharing them! Glad it turns out to be at least plausible. Thanks for taking the time to

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

2020-06-29 Thread 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. Could the conflictors be re-computed? In

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

2020-06-29 Thread 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 to files using UUIDs to get around > that.

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

2020-06-29 Thread 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 manually editing patches, and as > hinted

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

2020-06-29 Thread 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 about so called "Duplicates" in the darcs-2

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

2020-06-28 Thread James Cook
> That said, you should be advised that both patch theory implementations > ("formats") currently in use, namely darcs-1 and darcs-2, have bugs. In > practice that means you may not be able to do such a separation for > complicated conflict scenarios, though I think if it succeeds then the >

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

2020-06-26 Thread 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") > > * Therefore, B'A' does the same thing

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

2020-06-25 Thread James Cook
Thanks, Ben! Responses inline. If you have the time, I'd be curious to hear about why my expectations didn't match what darcs actually did. > > 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. > > >

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

2020-06-25 Thread James Cook
(re-sending 3 days later; sorry if this arrives twice) Hi darcs-users, I'm trying to learn more about how darcs force commutes work. 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