We now have bugs/issue525.sh which reproduces an amend-record version of this bug.

I was able to reproduce this (although not in a controlled way, yet).  I can
confirm that amend-record is involved.  I'm guess that it's because of the
coalesced nature of hunks?

smime.p7s files are S/MIME signatures of my emails, so they are not related to
the bug.
The problematic patch is available here:
http://re.jabber.ru/~alexey/ejabberd/_darcs/patches/20070829175459-e83eb-caf1155b92f3adec1f8f1c9ffbded79efa7a891a.gz
I'll try to find out how to reproduce it with darcs 1 and 2.

Alexey,

I'm not familiar with this "p7s" format. Is there any chance you could test
again with a build of a Darcs 2 pre-release binary? There are some pre-built
from the DarcsTwo page on the wiki. 

Short of that, re-sending a test case in a more common format would be helpful.

I'll do some testing with the provided examples.

DR> I don't think amend-record should be responsible.  It ought to be possible
 DR> to reproduce this.  If you grab a repository with one of these two as the
 DR> last patch, unrecord and then record again, does it result in the same
 DR> diff?

The patch I showed in the first message becomes correct after unrecord/record.
The other patch doesn't change, but I found that it's because TAB was
accidentally inserted in the line 7.  Probably a more human-friendly patch
would be this:

hunk ./ChangeLog 1
+2007-08-29  Mickael Remond  <mremond@process-one.net>
+
+	* doc/guide.tex: Documentation for XML based optimisation build
+	time option (EJAB-298)
+
hunk ./ChangeLog 7
-
+^I

but it has the same number of lines, so I think there is no issue with the
second patch.

...
> is a result of tailor svn->darcs gate, and I believe it doesn't use
> amend-record.

I don't think amend-record should be responsible.  It ought to be possible
to reproduce this.  If you grab a repository with one of these two as
the last patch, unrecord and then record again, does it result in the same
diff? (Yes, I could test this myself, but I'm trying to focus on
conflicts...)
-- 
David Roundy
http://www.darcs.net

Hi!

 TP> Was the patch recorded with Amend-record? If it was, it's probably just a
 TP> matter the Amend-record not being totally optimized, but the patch should
 TP> be fine although odd looking.

Yes, the first one was altered with amend-record to resolve a conflict, however
this one
http://re.jabber.ru/~alexey/ejabberd/_darcs/patches/20070829161259-9f22b-1bdefba7d07cdcbf79431c0e7de9e8a2ac4f7635.gz
containing

hunk ./ChangeLog 1
-2007-08-29  Alexey Shchepin  <alexey@process-one.net>
+2007-08-29  Mickael Remond  <mremond@process-one.net>
+
+	* doc/guide.tex: Documentation for XML based optimisation build
+	time option (EJAB-298)
hunk ./ChangeLog 6
+2007-08-29  Alexey Shchepin  <alexey@process-one.net>
+	

is a result of tailor svn->darcs gate, and I believe it doesn't use
amend-record.

Yes, that is puzzling.  It seems that there's a pretty severe infelicity in
our diff algorithm.  :( On the plus side, it doesn't cause corruption, but
it'd also be nice to figure out what triggers this.
-- 
David Roundy
http://www.darcs.net

Was the patch recorded with Amend-record? If it was, it's
probably just a matter the Amend-record not being totally
optimized, but the patch should be fine although odd looking.

Hi Alexey,

[pre-pended lines]
> +2007-08-29  Mickael Remond  <mremond@process-one.net>
> +
> +	* doc/guide.tex: Documentation for XML based optimisation build
> +	time option (EJAB-298)

That does not look expected to me, but maybe David should comment.
Does 1.0.9 or perhaps the current stable branch of darcs behave the
same way?

In any case, thanks for the bug report!

Hi!

Today I noticed that sometimes darcs generates strange patches:
http://re.jabber.ru/~alexey/ejabberd/_darcs/patches/20070829161259-9f22b-1bdefba7d07cdcbf79431c0e7de9e8a2ac4f7635.gz
http://re.jabber.ru/~alexey/ejabberd/_darcs/patches/20070829175459-e83eb-caf1155b92f3adec1f8f1c9ffbded79efa7a891a.gz

Look at first hunks, they remove, and then add back the same lines:

hunk ./ChangeLog 1
-2007-08-29  Mickael Remond  <mremond@process-one.net>
-
-	* doc/guide.tex: Documentation for XML based optimisation build
-	time option (EJAB-298)
+2007-08-29  Alexey Shchepin  <alexey@process-one.net>
+
+	* src/mod_muc/mod_muc_room.erl: The mod_muc option max_users now
+	limits max number of users in rooms and max_users_admin_threshold
+	sets a number of admin or owner accounts allowd to join after
+	max_users occupants
+
+2007-08-29  Mickael Remond  <mremond@process-one.net>
+
+	* doc/guide.tex: Documentation for XML based optimisation build
+	time option (EJAB-298)

While I expected to see this:

hunk ./ChangeLog 1
+2007-08-29  Alexey Shchepin  <alexey@process-one.net>
+
+	* src/mod_muc/mod_muc_room.erl: The mod_muc option max_users now
+	limits max number of users in rooms and max_users_admin_threshold
+	sets a number of admin or owner accounts allowd to join after
+	max_users occupants
+

Am I missing something and this is an intended behaviour, or is it a bug?
Darcs version is 1.0.9~rc1-0.1 (from debian etch).