Re: Idea: add support for rsync-style filter files

Most of this functionality is already present in Unison’s existing preferences.  There may be room for small extensions, but the main design issue is dealing with situations where the set of paths to be ignored is different (for whatever reason) on the client and server.

    - B

> On Feb 4, 2015, at 8:53 AM, martin f krafft <[email protected]> wrote:
> 
> 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: [email protected]
> _______________________________________________
> Unison-hackers mailing list
> [email protected]
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

_______________________________________________
Unison-hackers mailing list
[email protected]
http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers