[Unison-hackers] Idea: add support for rsync-style filter files

[martin f krafft]

Hello,

over at
https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11460,
the discussion about skipping hierarchies based on files present on
the filesystem has started anew. I confess that I have not
thoroughly researched all of the past regarding previous
discussions, but I would like to propose a way forward. If there's
a past discussion I missed, I would appreciate a pointer.

rsync(1) has a pretty nifty filter file specification, and I think
it would make most sense for unison to adopt it, at least in part.¹

¹) http://blog.mudflatsoftware.com/blog/2012/10/31/tricks-with-rsync-filter-rules/
and http://www.samba.org/ftp/rsync/rsync.html

Benjamin highlighted the main design decision that needs resolution
as being that we have to decide what to do if the filters in the two
locations (source and replica) disagree. And I would like to propose
a very simple approach and solution to this:

  1. only filters in the local (origin) replica apply. Ignore rules
     in remote profile files also don't apply, so this feels natural
     and should simplify the implementation a lot;

  2. the filter rules themselves are flexible enough to allow the
     user to individually select whether to sync the filter files
     themselves with the remote (local → remote only). This is
     similar to giving users the choice of whether to sync ~/.unison
     or parts thereof;

  3. if a filter file is retrieved from the remote, it only starts
     taking effect during the next unison run. A (configurable)
     warning could be issued if such a file is transferred and it's
     foreseeable that it'll affect future runs. This fetching could
     also be disabled with a configuration option;

  4. The name(s) of the file(s) containing filter rules could/should
     be configurable similar to how merge/diff is configurable, i.e.
     by path.

What do people think about this? Is this too simple or too complex?
Does it fall short anywhere, or is this a viable path? What are the
open questions?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
tempt not a desperate man.
                                                -- william shakespeare
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1107 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150204/f6a5a399/attachment.asc>