On Fri, Sep 10, 2021 at 08:19:29PM +0900, Stephen J. Turnbull wrote:
> James Cook writes:
>
> > For short-lived branches, I just use one clone per branch. I think this
> > should work well for long-lived branches too, but I haven't tried.
>
> What's nice about
> Is there a way to "cleanly" separate two different set of features,
> let's say "production" and debug ? The only way I've found would be to
> have 2 different repositories.
For short-lived branches, I just use one clone per branch. I think this
should work well for long-lived branches too, but
On Tue, Jan 26, 2021 at 08:49:30PM +0100, Ben Franksen wrote:
> Am 24.01.21 um 12:03 schrieb Ben Franksen:
> > A /realization functor/ R is a functor from abstract patches (sequences
> > of names and contexts) to concrete patches (with a commute function),
> > such that
> >
> > (a) R maps abstrac
Hi Ben,
Happy 2021! I let this thread drop for a while but trying to catch up now.
I think we had defined an abstract patch theory as a set of names, and
a set of possible "contexts" which are sets of names (or corners on the
hypercube), where the set of possible contexts satisfies (copying and
p
> Interesting! So corners (potential contexts) have an inherent partial
> order, indeed they form a join-semilattice. You postulate that if two
> contexts have an uppper bound that is also a context, then the minimal
> upper bound must also be a context. I think the math term would be that
> contex
On Sat, Dec 12, 2020 at 10:09:23PM +0100, Ben Franksen wrote:
> Am 12.12.20 um 18:54 schrieb James Cook:
> >>> As far as I can tell, the example is consistent with the patch theory
> >>> axioms in [0] and [1]: we can simply say that in our patch theory,
> >>&
On Sun, Nov 22, 2020 at 10:08:45AM +0100, Ben Franksen wrote:
> Am 21.11.20 um 20:39 schrieb James Cook:
> > I've been trying to put together a proof, and ran into a strange
> > example: what if AB and B' are both repositories, but A and B don't
> > commute? I.
On Sat, Dec 12, 2020 at 02:32:07PM +0100, Ben Franksen wrote:
> Am 12.12.20 um 11:56 schrieb Ben Franksen:
> > Another aspect not covered is that for permutivity to hold, we need not
> > only ensure a /minimum/ number of parallel paths, but also a /maximum/
> > number of intermediate contexts. The
On Sat, Dec 05, 2020 at 06:50:45PM +0100, Ben Franksen wrote:
> Hi James
>
> Thanks for your answers. It appears I had a completely wrong intuition
> about what a tree patch is. I was under the impression that it roughly
> corresponds to Darcs' named patches (changesets), but your definition
> see
> You are right. Such a scenario must not be allowed and the "global"
> definition of patch graph I gave is too weak to exclude it. If you
> analyse the counter example from the POV of permutations of names, what
> we have here is (indeed the simplest example of) a permutation group
> that is not g
On Tue, Nov 24, 2020 at 10:55:22PM +, Ganesh Sittampalam wrote:
> Hi,
>
> On 24/11/2020 21:43, James Cook wrote:
> > I wrote a description of how to store a repository as a tree of
> > primitive patches with active and inactive branches, as an alternative
> > to co
On Thu, Nov 26, 2020 at 02:32:08PM +0100, Ben Franksen wrote:
> Regarding Section 4.11, let me reformulate the main definition to make
> it a bit less awkward.
>
> A patch with name n is inactive with respect to a set of tree patches S
> if it is deactivated by any tree patch (P,D) in S (i.e. n is
On Thu, Nov 26, 2020 at 02:12:56PM +0100, Ben Franksen wrote:
> I would start the whole thing with a slightly different definition.
This seems like a nice way to do things. I like the reuse of terms from
category theory.
Do you happen to know how much this has in common with "A Categorical
Theory
On Wed, Nov 25, 2020 at 12:53:24PM +0100, Ben Franksen wrote:
> Two minor remarks.
>
> > 4.2.7 Reactivating a patch
> > As promised in Section 4.1.3, it is possible to re-activate a previously
> > deactivated patch p. First, it is likely the user will need to de-activate
> > patches p conflicts
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
&
I wrote a description of how to store a repository as a tree of
primitive patches with active and inactive branches, as an alternative
to conflictors. For context, see recent discussion on the thread
"How to extend a patch theory to fully commute".
It is Section 4 of this pdf: https://www.falsifia
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
> Property:
>
> (Summary: any sequence of patch names can be realized as a sequence of
> patches unless there's a specific conflict or violated dependency
> preventing it.)
>
> Let N be the set of (positive) patch names and C(N) the set of finite
> subsets of N.
>
> There exist:
> - a function "
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'
> >> on
I've been trying to put together a proof, and ran into a strange
example: what if AB and B' are both repositories, but A and B don't
commute? I.e. A can only be applied if B hasn't been applied yet, but B
doesn't depend on A.
My questions: Is this situation disallowed by some existing patch
theory
> > 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 conf
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 pat
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 follo
> >> 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
> >
> 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" (pri
(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 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
> p
> 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'
>
> > 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 exa
> >> 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 (ta
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 nam
> 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 fi
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 unders
> 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 cont
> >> 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 co
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 email
> > 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
> > transformations.
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
> > 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,
>
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
> 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 theor
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
> >>
> > 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,
> > 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 s
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 t
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
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 o
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, (Qi),
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), and
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" comm
> 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 l
> 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 sur
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.
>
> 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 used
> 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 is
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
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
== 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 ordina
> 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 respon
> 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 mo
> 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. An
> 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 above
> 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 for
> 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
> result
> > 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
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-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
70 matches
Mail list logo
