encode/decode filter weirdness

[Maquelin, Olivier]

>The filters are applied in exactly two places:
>
> - reading files from the working directory
> - writing files to the working directory
>
>Thus, the Mercurial internals never see files except in their
>canonicalized form. For instance, checking whether a file is changed
>is done by reading it from the working directory (w/filter) and
>comparing it to what's in the repo (unfiltered).
>
>> Now let's try to extract the canonical representation from the
>> repository by deleting the file and having it re-created:
>> 
>> [~/foo] rm foo.txt 
>> [~/foo] hg status
>> R foo.txt
>> [~/foo] hg revert
>> [~/foo] hg status
>> M foo.txt
>> [~/foo] hg diff
>> [~/foo] od -a foo.txt
>> 0000000   o   n   e  nl   t   w   o  nl
>> 0000010
>> 
>> The file contents are as expected, but why is 'hg status' 
>reporting the
>> file as being modified?
>
>Because the revert command changed the size of the file without
>changing the dirstate. The file is indeed changed.

Wouldn't this issue go away if the size of the filtered contents were
used instead of the size of the original file? Of course, this might
cause a significant performance hit.

>If your filters are not matched, you'll get interesting results.

Hmm... I had not realized there was such a limitation. I guess this
means I will have to be careful with clone/push/pull between Windows and
Linux, at least when communicating through a shared filesystem. For
example, instead of cloning a repository on Windows for later use under
Linux it seems I should create an empty repository from Linux, push (or
pull) into it and then update from Linux.

Btw, I just tried that and had to use 'hg push -f' to push a single,
initial changeset into an empty repository. Is that the expected
behavior (because the number of heads increases from 0 to 1)?

-- Olivier