[MERGE/RFC] Content filters - take 6

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Martin Pool wrote:
>> 2009/2/21 John Arbash Meinel <john at arbash-meinel.com>:
> 
>>>> If the filters are asymmetrical, then I think we may get the
>>>> following situation: when the tree is constructed it'll be given the
>>>> canonical hashes, but if we re-hash a file we'll see the hash that
>>>> comes from input filtering on the working copy.  That might be
>>>> reasonable if we saw them as changed when the user specifically
>>>> touched those files, but the problem is that we'll sometimes re-hash
>>>> them because the original timestamp was not safe.
>>> Do we want to support asymmetrical filters? It seems like we should only
>>> really allow filters where "in_filt(out_filt(bytes)) == bytes". Or do
>>> you have some otehr meaning here?
>> Well he does document later in the patch that such filters are allowed.
>>
>> If we're going to run arbitrary code for them it seems a bit hard to
>> forbid them.  And anyhow, there are interesting plausible cases, such
>> as normalizing something on checkout but always committing precisely
>> what was written.
>>
>> A filter that makes all files modified whenever you check out would be
>> strange I agree, but I'd like to at least know how it should work.
>>
>>>> Asymmetric filters are not the common case but I hoped considering
>>>> those cases would shed light on how it should work.
>>> IMO, if you have an asymmetric filter, you have just modified the whole
>>> working tree.
>> Agree - or at least, all the files for which it produced an asymmetric result.
> 
> I think asymmetric filters must be supported. It's easy to come up with
> cases where they are useful, e.g. one for removing trailing whitespace on
> commit. (That would certainly beat the current situation where PQM falls
> over on a failed test_coding_style test.)
> 
> Furthermore, most filters will be supplied by plugins and we have no
> control over whether such filters will be symmetric or not. It would
> be extremely hard to enforce this, e.g. testing on some "standard"
> dummy data isn't going to help because most filters, by their nature,
> are very data dependent.
> 
> Ian C.
> 

I think they should be supported. I just think that if you do "bzr co"
and have an asymmetric filter installed, it should tell you that all of
your files (that had their trailing whitespace stripped) are modified.

There is certainly an argument that we could say "these files aren't
modified since they were written to disk". Which would mean that it
strips all trailing whitespace, but only files that you actually modify
get committed (with the trailing whitespace stripped again). And then
the source tree should be updated with appropriate filters on the way back.

I realize you documented it differently, but if "commit" is going to
modify what is put into the repository, it should turn around and update
what is written on disk. Certainly if you want to support
$LastModifiedRevision$ you need to do that anyway.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmkD0AACgkQJdeBCYSNAAPLVwCfT0Ew3/H19mYT7LSGLStL/sx6
SIEAoJz1R7uJoTmbFWHmamOxDKKv1GKM
=Z1eY
-----END PGP SIGNATURE-----