On Sun, Nov 22, 2020 at 07:58:18AM +0100, Ben Franksen wrote:
> Am 21.11.20 um 22:25 schrieb James Cook:
> > I was, however, thinking that deactivation would be "permanent" or
> > "sticky", in the sense that once a prim patch has been deactivated, it
> > cannot be re-activated except by
Am 21.11.20 um 22:25 schrieb James Cook:
> I was, however, thinking that deactivation would be "permanent" or
> "sticky", in the sense that once a prim patch has been deactivated, it
> cannot be re-activated except by obliterating the thing that
> deactivated it.
What is that "thing that
On Sat, Nov 21, 2020 at 07:55:28PM +0100, Ben Franksen wrote:
> Am 21.11.20 um 03:13 schrieb James Cook:
> >>> How do we present this at the user level?
> >>>
> >>> The unresolved conflict is probably presented quite similar to how we do
> >>> it in Darcs now: we tell them that there is a conflict
On Sat, Nov 21, 2020 at 06:02:49PM +0100, Ben Franksen wrote:
> >> This suggests that we should present the "inactive" portions of a named
> >> patch in a special way e.g. "shaded"or with a bit of extra markup. In
> >> fact this may be superior to how Darcs operates today, where hitting 'v'
> >>
Am 21.11.20 um 03:13 schrieb James Cook:
>>> How do we present this at the user level?
>>>
>>> The unresolved conflict is probably presented quite similar to how we do
>>> it in Darcs now: we tell them that there is a conflict between A and B
>>> and present the alternatives a1 and b1 as the
>> This suggests that we should present the "inactive" portions of a named
>> patch in a special way e.g. "shaded"or with a bit of extra markup. In
>> fact this may be superior to how Darcs operates today, where hitting 'v'
>> on a conflictor shows you its internal representation, which isn't too
> > How do we present this at the user level?
> >
> > The unresolved conflict is probably presented quite similar to how we do
> > it in Darcs now: we tell them that there is a conflict between A and B
> > and present the alternatives a1 and b1 as the "content" of the conflict,
> > e.g. using
On Sat, Nov 21, 2020 at 12:55:04AM +, James Cook wrote:
> On Fri, Nov 20, 2020 at 06:45:49PM +0100, Ben Franksen wrote:
> > Am 20.11.20 um 13:24 schrieb Ben Franksen:
> > >> I would like a patch theory where
> > >> conflict resolutions are just new patches that replace the conflicting
> > >>
On Fri, Nov 20, 2020 at 06:45:49PM +0100, Ben Franksen wrote:
> Am 20.11.20 um 13:24 schrieb Ben Franksen:
> >> I would like a patch theory where
> >> conflict resolutions are just new patches that replace the conflicting
> >> ones, and don't depend on the patches they're resolving.
>
> What
Am 20.11.20 um 13:24 schrieb Ben Franksen:
>> I would like a patch theory where
>> conflict resolutions are just new patches that replace the conflicting
>> ones, and don't depend on the patches they're resolving.
What follows started out as describing a potential problem with this
idea, but in
Hi James
Am 19.11.20 um 22:44 schrieb James Cook:
I still wonder if a consistent patch theory *different* from
camp/darcs-3 could be devised in which conflict resolutions really are
freely exchangeable with the conflicted patches instead of depending on
them. In other words,
> >> I still wonder if a consistent patch theory *different* from
> >> camp/darcs-3 could be devised in which conflict resolutions really are
> >> freely exchangeable with the conflicted patches instead of depending on
> >> them. In other words, we may *choose* one of the conflicting patches as
>
Am 01.10.20 um 01:10 schrieb James Cook:
> Thanks. I have not read through the details in the camp paper or the
> Darcs V3 source code yet, but I think your explanation of conflictors
> above, and the connection to the tree point of view, gives me some good
> intuition to start with.
>
> I wonder
> In camp/darcs-3 (see src/Darcs/Patch/V3) a conflictor consists of three
> parts (all prim patches are of course named):
>
> * The effect (a sequence of prim patches that negate all patches that we
> conflict with, unless already negated by a previous conflictor),
>
> * a set of "contexted"
(new email address)
I'm hoping to do a little write-up of my idea for avoiding conflictors,
after working out some details. (Maybe I'll discover it doesn't work
out.)
For now though I have waited long enough to answer your email so here
goes...
> I am going to discuss only d here, we need to do
On 2020-09-17 16:38, Ben Franksen wrote:
> Also note that the "context" in a contexted patch usually
> consists of negated patches (we have to walk backwards along the history
> to reach the patch we reference).
Sorry, this is wrong. In fact, all contexted patches contain only
positive prims. We
>> Conflictors in Darcs can be seen as "internalizing" the relevant parts
>> of the above tree structure /into/ the (conflicted) patch
>> representation. This is the source of their complexity. What we gain
>> form that is the possibility arrange all patches in a repo in a linear
>> sequence where
Am 17.09.20 um 01:51 schrieb 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
>>
>>
> 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'
>
Hi James
I think I mentioned that inverses in patch theory always confuse me. So
I may be talking nonsense here.
My current thinking is this:
When we add names to primitive patches, we implicitly make the theory
asymmetric in the sense that /new/ patches can enter the scene only as
positive
> > 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
Am 08.09.20 um 21:47 schrieb 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
> >> 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
Am 08.09.20 um 17:29 schrieb 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
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
>>> 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 names).
>>> * A set of names, called "tombstones",
> 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
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
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 understood simply
> as "working tree states": the mapping from
Am 19.08.20 um 03:26 schrieb 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
Am 18.08.20 um 22:42 schrieb James Cook:
> Okay, I wrote something up: https://www.falsifian.org/a/xxOw/misc.pdf
I like it. Especially the part where you define commutation in terms of
the balance-respecting property. This is very elegant. It confirms what
I have long since suspected, namely that
> 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
> >> 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
Am 13.08.20 um 19:54 schrieb James Cook:
> Question: is there a good place to read about how "darcs pull" works?
I am not aware of anything that you could read. What happens is
basically this:
We read the _darcs/hashed_inventory of both the local and remote repo.
These give us the latest know
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
Am 08.08.20 um 22:51 schrieb James Cook:
>> Why are you so hung up on this tree / cycle thing? What is wrong about
>> your original context addresses and patch (sequence) adresses? If
>> efficiency is the concern, we are talking about a factor of two here.
>> This is irrelevant. For the theory you
> > 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
> >
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
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
> primitive context (e.g. this is true
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
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 unconflicted repository)
> >>> you can
> > 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,
>
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 so that they are all primitive.
>>
>>
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
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* recording a new patch, then this means you
> 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
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
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
> >>> are satisfied with the resolution that
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
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
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
> > 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,
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 merge A and B, then I use Proposition 5
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
> > 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
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 the process, you haven't
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
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 algorithm.
> >
> > * If
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
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 pair of adjacent
> > patches, the
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,
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),
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" commuting it. The new node is represented as
> 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
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
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
>
> 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
> 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
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?
>
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.
>>
> 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
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.
> >>
> >> That is, if we regard the primitive
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
> 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
>
> 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
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
> 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
>
> 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
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
permutation of (Qi) such that all the
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 in X come
>>> before patches with
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
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 is the after-context of
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 there, and b and c are the contexts after P1
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
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
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})
86 matches
Mail list logo
