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.
> 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
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
> 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
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
> 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
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
> 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
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")
>
> > 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
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
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.
> >
>
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
(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
17 matches
Mail list logo
