Sorry to reply to these messages out-of-order, but I think I can add a
couple things here.
On Mon, Sep 27, 2004 at 11:38:32AM +0100, Ralph Corderoy wrote:
> Everything OK so far, I decided to hunt down more simple documentation
> errors and ended up recording and sending another patch to David and got
> a different `applied' reply.
> ...
> We have conflicts in the following files:
> ./Repository.lhs
> Applying patches to the local directories...
> Finished applying...
>
> These being my first two darcs actions it wasn't clear to me from
> reading the documentation if my second patch was applied or whether the
> conflict meant it hadn't and it was up to me to resolve the conflict and
> send a new patch.
Not your fault--you don't have enough information. The only real way to
know the status of a patch is 1) have David tell you or 2) wait and see
if it shows up in the master repo.
> So I did a pull to get the patches David had that I didn't. It happens
> that the `Fix documentation typo' patch did the same thing as one of my
> edits.
>
> $ zcat 20040925214620-a1fc1-474c598e50fa045a1eb3af4e1e4f2994c1167ba3.gz
> [Fix documentation typo.
> fw@xxxxxxxxxxxxx**20040925214620] < > {
> merger 0.0 (
> hunk ./Repository.lhs 41
> -interperetation of the stored patches in this repository.
> +interpretation of the stored patches in this repository.
> hunk ./Repository.lhs 41
> -interperetation of the stored patches in this repository.
> +interpretation of the stored patches in this repository.
> )
> }
> $
>
> But I don't understand why the edit appears twice in the patch, it's
> probably something to do with /^merger/. Does that mean that fw@deneb
> was himself merging stuff or is the patch file I've got different from
> what he created because it conflicted with my repository?
It means that fw@deneb created a patch with the exact some change as
yours, and David already applied it. Note that these are not the same
patches--they have independent identities (which is why they conflict)
even though they do the same thing. And no, fw@deneb was not doing any
merging, your second idea is right: In his repo (and David's), it just
looked like a normal patch, and only when it came to your repo did it
morph into a merger. (And in David's scratch repo, your patch became a
merger.) Anyway, in principle, you shouldn't have to know anything
about this, but if you want to, read the theory section and scratch your
head for a while.
> I can see that conflicts need to be resolved by a third patch as opposed
> to CVS's `resolve conflicts before you can check in' model. But do I
> have to specify that my resolving patch depends on the other two?
No, darcs figures out these dependenecies itself.
> Is this the normal way of showing a unresolved conflict?
Not exactly, it's a quirk of the fact that both patches did the same
thing, as I said in my first message.
Andrew
|
