Created on 2007-06-21.04:25:38 by narge, last changed 2009-08-27.13:58:02 by admin.
msg1742 (view) |
Author: narge |
Date: 2007-06-21.04:25:31 |
|
This bug was seen in a project with around 700 patches. I'm not sure what caused it,
and couldn't reproduce it in a new repository.
In File.lhs, line 69 is empty. Patch A, in the repostitory, adds another empty line at
line 70. Patch B, being pulled from a branch that doesn't have patch A, adds a block of
code at line 70, including a new empty line at the end.
The output of darcs whatsnew after pulling patch B is something like:
hunk ./File.lhs 70
+v v v v v v v
+
+*************
+> f :: A -> M ()
+> f a = error "Blah"
+
+^ ^ ^ ^ ^ ^ ^
I then resolve the conflict by keeping the new code, and record patch C:
hunk ./File.lhs 69
+
+> f :: A -> M ()
+> f a = error "Blah"
However, the conflict still exists. Running resolve adds a second copy of the new code
to the file. This was a rather confusing situation.
I eventually discovered a workaround, by unpulling patch C and removing both empty
lines, then recording patch D:
hunk ./File.lhs 69
-
+> f :: A -> M ()
+> f a = error "Blah"
At this point, there was no more conflict. After replacing the empty lines and using
amend-record, patch D became:
hunk ./File.lhs 70
+> f :: A -> M ()
+> f a = error "Blah"
+
Which still resolves the conflict, and has the desired effect on the file.
|
msg1743 (view) |
Author: kowey |
Date: 2007-06-21.05:59:32 |
|
Hi,
> I then resolve the conflict by keeping the new code, and record patch C:
>
> hunk ./File.lhs 69
> +
> +> f :: A -> M ()
> +> f a = error "Blah"
>
> However, the conflict still exists. Running resolve adds a second copy of the new code
> to the file. This was a rather confusing situation.
I'm not sure what you mean by "the conflict still exists". It seems
like your patch C is a perfectly adequate resolution.
Also, resolve did exactly as it it should. The problem is just that
it is poorly named and really ought to be called 'mark-conflicts'.
http://bugs.darcs.net/issue113
|
msg1744 (view) |
Author: narge |
Date: 2007-06-21.06:20:30 |
|
> I'm not sure what you mean by "the conflict still exists". It seems
> like your patch C is a perfectly adequate resolution.
Yes, it seems like it is an adequate resolution, but it isn't. After recording patch
C, darcs resolve (or darcs mark-conflicts, if you prefer) still believes that there
is a conflict, and marks it again, rather than printing "No conflicts to resolve."
Patch D (after amend-record) has the same effect on the contents of the file, and
does resolve the conflict.
> Also, resolve did exactly as it it should. The problem is just that
> it is poorly named and really ought to be called 'mark-conflicts'.
> http://bugs.darcs.net/issue113
I'm aware of that. There shouldn't be a conflict to mark, after patch C has been
recorded.
|
msg3274 (view) |
Author: markstos |
Date: 2008-02-09.18:46:34 |
|
Narge,
I suspect that your issue is now resolved with Darcs 2 which would not consider
two identical whitespace patches a conflict anymore. You can confirm this with a
prerelease binary here:
http://wiki.darcs.net/index.html/DarcsTwo
Run "darcs convert your_repo"
To translate the repo format, and then try again.
We'll likely consider this resolved unless we hear back from you that this is
still triggered for you with Darcs2.
|
msg3312 (view) |
Author: narge |
Date: 2008-02-11.04:46:54 |
|
darcs convert doesn't preserve conflicts (see msg2938). So reproducing the bug
with a converted copy of my repository is currently impossible; I just end up
with a version of patch B that doesn't contain the conflicting primitive patch.
As I said in my original report, I haven't been able to reproduce this in a new
repository (though I suspect it involves using amend-record on A or B, or one of
the patches they depend on). So until darcs convert preserves conflicts, I have
no way to tell whether darcs 2 resolves the issue.
|
msg3313 (view) |
Author: kowey |
Date: 2008-02-11.11:19:37 |
|
I wonder if there is anything notable about the fact that the conflict (see
original post) is marked starting from line 70, and the resolution patch from
line 69.
|
msg3315 (view) |
Author: markstos |
Date: 2008-02-11.15:00:25 |
|
Thanks for the follow-up, Narge.
I'm tempted then to consider this "resolved-in-unstable" until we have a case
that triggers it there.
|
msg4412 (view) |
Author: kowey |
Date: 2008-04-30.19:39:17 |
|
Treating this as presumed-dead.
We don't actually know if it has been resolved, but we need an example. If you
could get back to us with such an example, we'd be grateful. Otherwise, we're
assuming it's something darcs2 fixed.
|
|
Date |
User |
Action |
Args |
2007-06-21 04:25:41 | narge | create | |
2007-06-21 05:59:33 | kowey | set | status: unread -> unknown messages:
+ msg1743 |
2007-06-21 06:20:31 | narge | set | nosy:
kowey, beschmi, narge, droundy, tommy messages:
+ msg1744 |
2007-07-23 20:57:24 | kowey | set | topic:
+ Conflicts |
2008-02-09 18:46:35 | markstos | set | status: unknown -> testing nosy:
+ markstos messages:
+ msg3274 assignedto: narge |
2008-02-11 04:46:55 | narge | set | nosy:
droundy, tommy, beschmi, kowey, markstos, narge messages:
+ msg3312 |
2008-02-11 11:19:38 | kowey | set | nosy:
droundy, tommy, beschmi, kowey, markstos, narge messages:
+ msg3313 |
2008-02-11 15:00:26 | markstos | set | nosy:
droundy, tommy, beschmi, kowey, markstos, narge messages:
+ msg3315 |
2008-04-30 19:39:18 | kowey | set | status: testing -> resolved nosy:
+ dagit messages:
+ msg4412 |
2009-08-06 17:41:30 | admin | set | nosy:
+ jast, Serware, dmitry.kurochkin, darcs-devel, zooko, mornfall, simon, thorkilnaur, - droundy, narge |
2009-08-06 20:38:42 | admin | set | nosy:
- beschmi |
2009-08-10 22:05:37 | admin | set | nosy:
+ narge, - darcs-devel, zooko, jast, Serware, mornfall |
2009-08-11 00:01:12 | admin | set | nosy:
- dagit |
2009-08-25 17:55:06 | admin | set | nosy:
+ darcs-devel, - simon |
2009-08-27 13:58:02 | admin | set | nosy:
tommy, kowey, markstos, darcs-devel, narge, thorkilnaur, dmitry.kurochkin |
|