c.caughie at indigovision.com
Thu Dec 3 07:42:18 CST 2009
> > Unfortunately I can't see any way of addressing this in the
> > without changing the way core hg does patching, i.e. to make it
> > the repo filters as I originally proposed. And frankly I find the
> > thought of opening that argument up again somewhat daunting...
> I haven't looked at the old discussion yet. Is the problem you're
> talking about the same as this one:
Not quite, but it's related.
> Diffs are computed based on the encoded forms of files. This little
> script illustrates it in a nice blunt way on Linux:
> hg init encode-test.$$
> cd encode-test.$$
> echo 'Hello World' > hello.txt
> cat > .hg/hgrc <<EOF
> ** = tr a-z A-Z
> ** = tr A-Z a-z
> hg add hello.txt
> hg diff
> cd ..
> rm -r encode-test.$$
> It asks Mercurial to "encode" files when saving them by making the
> content uppercase, and to "decode" them into the working copy by
> content lowercase.
> The problem is the diff: it looks like this:
> diff --git a/hello.txt b/hello.txt
> new file mode 100644
> --- /dev/null
> +++ b/hello.txt
> @@ -0,0 +1,1 @@
> +HELLO WORLD
> That is, it works on the encoded form instead of the decoded form. I
> would expect it to be all lowercase since that is the logical change
> the users environment.
> However, one could argue that the diff *should* be in uppercase
> that is the correct patch, i.e., the one that will apply in another
> clone that does not have the encode/decode filters installed.
I agree with the second argument; diffs should be based on the encoded (i.e. repository) form so that the same patches can work regardless of whether you have the filters enabled.
The problem is that although diff correctly honours the encode/decode filters, patch (specifically patch.applydiff) doesn't. Patching always operates on the working directory files, not the "logical" repo files. So although your capitalized "HELLO WORLD" patch would apply fine on a repo *without* the capitalization filters, it doesn't apply on the repo that has them enabled. In other words, having exported a patch from your translation-enabled repo, you couldn't then import this patch back into the same repo.
The patch.eol fix in 1.3 works around this by adding an option to have patch ignore line ending style entirely. But if we plan to make the line ending translation rules more sophisticated than they are in win32text, I would prefer to have a patch function that is genuinely complementary to the diff function, so that we can be more confident that it will always work.
Latest News at: http://www.indigovision.com/news2009.php
More information about the Mercurial-devel