[darcs-users] Data loss bug when renaming and replacing a non standard token?
kowey at darcs.net
Mon Mar 23 09:21:19 UTC 2009
On Sun, Mar 22, 2009 at 22:55:37 +0200, Dan Pascu wrote:
> It seems that this happens if you do not have an external-merge option
> defined in ~/.darcs/defaults or you do not specify one on the command
> line, but use --mark-conflicts (or don't use any ---xxx-conflicts).
So we can think of --mark-conflicts as being yet another merge tool
like one you would supply with external merge (only that it is
understands darcs things like replace and move patches, whereas the
external merge tool does not)
It's funny because your result is:
allow-conflicts : leaves a replace patch in unrecord
mark-conflicts : nothing new
Now with external merge (sans saving)...
> $ cat testdata
> Given %r/I have a file%r/ do
> $ darcs whatsnew
> replace ./testdata [%r/] / %r/
This isn't surprising because it's just what allow-conflicts does.
> 2.2 If I save the merged result from kdiff3, then I get the following
> hunk ./testdata 1
> -Given %r/I have a file%r/ do
> +Given /I have a file/ do
> +Given %r/something else/ do
> addfile ./testdata.orig
> hunk ./testdata.orig 1
> +Given %r/I have a file%r/ do
No surprise there, as far as I can tell. In fact, this is the result
we want, right?
> 1. Why --allow-conflicts has a reversed replaced applied to working copy?
Right. Shouldn't allow-conflicts just nullify both patches?
It's almost as if --allow-conflicts and --mark-conflicts have the
> 2. Why both --allow-conflicts and --mark-conflicts have removed the
> unrecorded lines.
> With --external-merge defined there are more questions though:
> 1. If external-merge is defined in defaults, --xxx-conflicts are
> completely ignored. I believe the external merger should not be used if I
> explicitly indicate on the command line --dont-allow-conflicts. I'm not
> sure what should happen with --allow-conflicts.
That sounds like a bug for which we ought to have a regression test.
> 2. Even though there was a replace patch that changed '%r/' to '/', in the
> merged result, the lines that were added but not yet recorded in repo2,
> still contain %r/. I was under the impression that a replace patch is
> useful exactly for these situations as it will combine with the changes
> that may have still added the old token on the receiving side and change
> those entries to the new token as well. But here we see that the newly
> added lines kept the original token and were not affected by the replace
> patch. Is this expected behavior, and if so what is the usefulness of a
> replace patch if it doesn't do more than a find/replace in the editor
> does? At least the documentation explained this expected behavior for the
> replace patch and use it a a reason why the replace patch is better than
> a find/replace in the editor.
Not having had a chance to think too carefully about this, I think this
is a consequence of darcs's behaviour of nullifying both sides of the
conflict first (and only adding stuff on top of it later in
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the darcs-users