On 7/10/24 8:00 PM, Henning Thielemann wrote:
>
> Years ago I did a one-time conversion of a Git repository to Darcs. Now
> I want to reactivate and resynchronize to the old Git repository.
>
> I created darcs.marks and git.marks manually, both ending with the same
> patch. However, it appears th
Hello Everyone
On behalf of the Darcs team, I would like to (somewhat belatedly)
announce the release of Darcs 2.18.3 [1].
This is a minor bug fix release. The main issue was that Darcs failed to
work on Windows when built with ghc >= 9.6. The reason was a bug in some
recent versions of the
On 1/18/22 17:57, Karl O. Pinc wrote:
FYI, the search box on darcs.net is broken. You get:
Happstack 7.5.1.3
Your file is not found
To try again is useless
It is just not here
I tried to find out what's wrong but failed miserably.
http://darcs.net/_history works, but http://darcs.net/_searc
Sorry for the (extremely) belated reply.
It is currently not possible to do this because we use some ancient
self-written code to format the timestamp that doesn't take system
settings such as your current locale into consideration.
It would be easy to change that -- in fact this is a perfect
be a different option
(named "remove-conflicting" in the list I gave). I'd say let's
concentrate on getting --mirror (aka --remove aka --obliterate) right
before we move on to other strategies.
Cheers
Ben
Ben Franksen writes:
Go ahead. Feel free to amend my patch as y
Am 15.09.21 um 05:21 schrieb Stephen J. Turnbull:
James Cook writes:
> > All of this is obviously quite possible with Darcs. The problem is
> > getting the "accounting" right when separating the management of
> > *sets* of patches from the management of *histories*. IIRC, in Darcs
> > t
Am 13.09.21 um 22:17 schrieb James Cook:
On Fri, Sep 10, 2021 at 08:19:29PM +0900, Stephen J. Turnbull wrote:
All of this is obviously quite possible with Darcs. The problem is
getting the "accounting" right when separating the management of
*sets* of patches from the management of *histories*.
Hi Ganesh
I guess this is a problem related to the roundup migration. If you could
take a look at that?
I tried twice to create an account with this email, but submitting the form
fails with:
Form is corrupted, missing: opaqueregister.
(BTW we should really add TLS/SSL to the website an
Am 11.09.21 um 17:47 schrieb Alexis Praga:
I wanted to build darcs from source and I have a few remarks:
1) The documentation says `cabal install darcs` but it's `cabal install
exe:darcs` instead
It may be necessary to be more specific when you invoke `cabal install`
from inside a project's s
Am 11.09.21 um 00:27 schrieb Alexis Praga:
Thanks Ben for the very interesting answer.
I wanted to take a stab at it as a newcomer, but you've been quicker !
Sorry!
I can look into adding a warning and interactively select the patches
though.
Go ahead. Feel free to amend my patch as you see
See http://bugs.darcs.net/issue2683
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
Hi Alexis
James answered you second question: I am indeed planning to implement
branches a la git in darcs and have layed some groundwork, but since we
are so few developers and can only work on darcs in our free time,
progress is not as fast as I would like.
Am 07.09.21 um 12:08 schrieb Ale
Am 28.08.21 um 23:03 schrieb Alexis Praga:
I'm trying darcs again since a few days and have hit an issue when
cloning a (non-empty) repository hosted on hub.darcs.net.
The error is:
Done fetching and unpacking basic pack.
Copying patches, to get lazy repository hit ctrl-C...
Exception while gett
I accidentally included links to version 2.16.3. Sorry for that. Here
are the correct links:
[1] https://hackage.haskell.org/package/darcs-2.16.4
[2] https://hackage.haskell.org/package/darcs-2.16.4/changelog
___
darcs-users mailing list
darcs-users@osuo
On behalf of the Darcs team, I would like to announce the release of
Darcs 2.16.4 [1].
Quoting from the release notes [2]:
This release is mostly to fix http://bugs.darcs.net/issue2674 which can
lead to repository corruption. This is not quite as bad as it sounds,
since the broken changes that yo
Am 15.04.21 um 16:03 schrieb Harald Geyer:
> Has anybody tried to get the patch theory work with xml files in a way,
> that uses DOM semantics. How difficult would it be to implement this?
I don't think this has been tried in the context of Darcs patch theory.
I see no principle difficulty, though
Am 25.03.21 um 09:30 schrieb Henning Thielemann:
>
> Is there currently a way to synchronize between a Darcs and a Subversion
> repository, i.e. can I submit darcs patches as commits to a Subversion
> repository and can I convert Subversion commits to darcs patches
> incrementally?
To my knowledg
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 abstract paths to concrete paths of the same length
> (b) fo
Am 22.01.21 um 23:42 schrieb James Cook:
> I think I am closer to understanding what you mean by "concrete patch",
> but I think I haven't got it completely.
>
> Here's my understanding so far:
>
> a) We begin with a set S of states. In the case of Darcs, that's the
>Tree type.
>
> b) A conc
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 context.
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 th
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
>
Am 12.12.20 um 18:22 schrieb James Cook:
> 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
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 cl
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
balancing" axiom.
But is that really the case? Can we derive all the required properties
(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 i
hrieb 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
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
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, wi
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
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 calle
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 a
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".
>
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 th
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 deactivat
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 "conte
et more detailed information 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
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 pr
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, we
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
(i.
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 m
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
https://lists.osuosl.org/mailman/listinfo/darcs-u
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 s
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] https://hackage.haskell.org/package/darcs-2.16.3/chang
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
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
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
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 defaultr
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 repo,
>> 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
>>
>> a--b
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 patc
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 t
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:
>>>>>
>>> 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", representing
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 o
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
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
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
obtai
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 cle
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
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 cate
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
>>&
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 me
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
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
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 words,
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 in
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 sho
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.
>>
>> Suppo
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
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 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
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
> between.
> 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 s
> 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 (Qi).
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.
>> In
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 in
> 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
> sequen
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 t
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
>>>
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 c
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 before-co
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 t
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}) point
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.
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
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 ma
Am 29.06.20 um 12:53 schrieb James Cook:
>> Converting existing repos to darcs-3 is unfortunately one of the things
>> we havent't done yet. I have implemented a number of conversion schemes
>> but they all fail in some situations. There are two hard problems to
>> solve here:
>>
>> (1) What to do
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
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")
>
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 tri
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
> force-comm
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 wo
Am 05.02.20 um 23:28 schrieb Ganesh Sittampalam:
> On 05/02/2020 15:28, Benjamin Franksen wrote:
>> Am 04.02.20 um 16:22 schrieb Henning Thielemann:
>>> http://darcs.net/ says:
>>>
>>> Service Temporarily Unavailable
>>>
>>> The server is temporarily unable to service your request due to
>>> mainte
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. [1
1 - 100 of 141 matches
Mail list logo
