Re: [darcs-users] preparing a 2.14 release

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

Re: [darcs-users] force commuting in practice

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

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] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

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

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

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

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

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] How to extend a patch theory to fully commute

>>> 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",

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

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

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

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: >>>>>

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

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

Re: [darcs-users] stack install darcs is broken

Am 15.10.20 um 20:41 schrieb Ilya Perminov: > Currently "stack install darcs" attempts to install 2.16.2 and fails with > Error: While constructing the build plan, the following exceptions were > encountered: > > In the dependencies for darcs-2.16.2: > sandi must match >=0.4 && <0.6, but the

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

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 "w

[darcs-users] [ANN] Darcs 2.16.2 release

On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.2. It turned out that darcs-2.16.1 cannot be built by downloading the source tar ball, unpacking it, and then running 'cabal install' inside the source folder. We have released Darcs 2.16.2 to fix this. There are no

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

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

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

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

[darcs-users] RFC: Hiijacking Patches

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 private email address. I want to decide which one to use per

[darcs-users] RFC: safer default for patch editing operations

Hi Everyone Since 2.16 the --not-in-remote option is supported for all operations that edit the history: amend, rebase suspend, obliterate, and unrecord. Should we make this the default behavior? My rationale is that this is usually what you want. Unless modified with --set-default, the

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

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

Re: [darcs-users] RFC: Hiijacking Patches

Am 25.09.20 um 16:42 schrieb James Cook: > Is hijacking patches a common operation for anyone? The least > surprising behaviour would be to always ask the user what to do if > they haven't explicitly chosen an option on the command line; I'd > certainly prefer that. But I've never needed to hijack

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

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 >> >>

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

>> 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

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

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

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

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

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

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

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

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?

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> 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] Make darcs force-commute patches from CLI, to learn about darcs?

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?

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?

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?

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?

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?

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

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

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

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

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

[darcs-users] [ANN] Darcs 2.16.1 release

Hi Everyone On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.1. This new release [1] contains a rather large number of bug fixes and many other goodies. If you are interested in the details, please look at the CHANGELOG [2]. The most up-to-date documentation is

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

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 with, as well as patches that conflict with p’s > dependencies if those

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

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

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

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

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

I would start the whole thing with a slightly different definition. Let N and C be sets. Elements of N will be called names and elements of C will be called contexts. Let G be a directed acyclic N-labelled C-graph. In other words, an edge in the graph is an element of P:=C*C*N. The edges are

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

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 in D), subject to the side condition that there exists no patch name m

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

Am 05.12.20 um 01:47 schrieb James Cook: > Recording for the list: > > On IRC, mornfall found a link to the writeup in question: > http://darcs.net/Ideas/NewRepositorySemantics > > They also pointed to a later idea they had which is written up at > http://paradise.fi.muni.cz/~xrockai/dvs.html,

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

Am 05.12.20 um 00:09 schrieb James Cook: > 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. > &g

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

James Cook: > 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 d

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

Am 24.11.20 um 22:43 schrieb James Cook: > 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".

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

Am 13.12.20 um 11:16 schrieb Ben Franksen: > However, remember your counter example of a patch universe with only two > paths with names abc and cba. From the presence of both {a} and {c} we > can deduce that of {a,c}, but it seems impossible to prove that {b} is > present. For

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

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 extreme case is the commuting > hypercube of dimens

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

roperties (i.e. exclude all pathological cases) for the subset of paths consisting only of positive patches? If this is indeed the case, then it would be quite a feat and perhaps worth the bit of extra complexity in the definition. Cheers Ben Am 05.12.20 um 18:41 schrieb Ben Franksen: > Am 05.

Re: [darcs-users] If AB and B' are repos, does that imply A and B commute?

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, >>> nothing ever commutes, and then the axioms don't have much to say. >>> >>> The Camp theory pdf [2] makes a

Re: [darcs-users] Write-up on "tree repositories" as an alternative to conflictors

Am 19.12.20 um 05:00 schrieb James Cook: >> 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

Re: [darcs-users] If AB and B' are repos, does that imply A and B commute?

Am 12.12.20 um 22:09 schrieb Ben Franksen: > Let me reformulate the idea, as I understand it, to simplify and > generalise it. > > It seems what you are after is similar to having a cache that, for every > patch p in the repo, stores what p looks like if commuted to its >

Re: [darcs-users] Request for more details

Hi Dalon Am 10.11.20 um 14:51 schrieb Dalon Work: > I recently discovered Darcs, and probably like lots of people, I'm very > intrigued by the "Patch Theory" behind it. I've read everything I could > find, and to be fair, much of it was over my head. I think I understand the > basic ideas, but I

Re: [darcs-users] Request for more details

I should have mentioned perhaps that one of the usual patch laws is that commutation is indeed a function i.e. there is at most one solution to AB=B'A'. ___ darcs-users mailing list darcs-users@osuosl.org

Re: [darcs-users] Request for more details

Am 11.11.20 um 13:58 schrieb Ben Franksen: > I should have mentioned perhaps that one of the usual patch laws is that > commutation is indeed a function i.e. there is at most one solution to > AB=B'A'. More formally correct, for given patches AB, the equation AB=xy has at most one no

Re: [darcs-users] Request for more details

Am 12.11.20 um 13:21 schrieb Dalon Work: > Ah, I figured it out. The baseline when importing patches is the set of > patches common to the two repositories. Exactly. It is never allowed to "just apply patches and see if that works". Instead, a patch is only valid in either its original context

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

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,

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

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 prob

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

ion about the patch. This is the same when you pull or push or whatever. Hitting '?' will display help about the available keys. Example: >darcs log -i patch a4b12fc212dadeacd92c47b262ff999db6451a69 Author: Ben Franksen Date: Tue Nov 3 00:39:30 CET 2020 * resolve issue2632: remove cont

Re: [darcs-users] If AB and B' are repos, does that imply A and B commute?

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.e. A can only be applied if B hasn't been applied yet, but B > doesn't depend on A. > > My questions: Is

[darcs-users] [ANN] Darcs 2.16.3 release

On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.3 [1]. This release fixes a number of minor issues and build problems. See the changelog [2] for details. [1] https://hackage.haskell.org/package/darcs-2.16.3 [2]

  1   2   >