[Unison-hackers] Ignore files above a certain size

[Benjamin Pierce]

Ok, this approach seems reasonable. The only thing that concerns me is adding one more ad hoc preference...

       - Benjamin

On Mar 7, 2013, at 10:28 AM, Alan Schmitt <alan.schmitt at polytechnique.org> wrote:

> Benjamin C. Pierce writes:
> 
>> An even easier way is to deal with such files at reconciliation time.
>> We've already got mechanisms and preferences for overriding Unison's
>> default reconciliation decisions based on many sorts of conditions
>> (which file is newer, etc.). The downside is that large files will
>> not, then, be completely ignored -- they will show up in the user
>> interface as conflicts.
> 
> I think that's a good thing that they show up in the interface, so that
> the user may decide to propagate them anyway.
> 
> Looking at the code, it seems the simplest is to extend shouldCancel for
> this. This is much nicer than the "Error" approach: if A is deleted and
> B is unchanged but above the limit, in the "Error" approach nothing
> happens, in the "shouldCancel" approach B is deleted.
> 
> I was also looking at how to log which files have not been transferred
> because of their size, and one way to do it is to add an argument to
> Conflict (similar to the one for Problem) that gives the cause of the
> conflict. This way it would be in the log and could be use in the UIs.
> 
>> Arguably, the right thing to do is to truly ignore such files. This
>> will be a bit harder to implement, since it will have to start with
>> generalizing the current ignore mechanism to take into account current
>> information from the filesystem beyond just path names. And it will
>> require a bit of care in reconciliation (because a file may then be
>> ignored on one side and not the other and we'll want to make sure we
>> correctly detect this situation and don't do something silly like
>> delete one of the copies) and in the UI (because we'll have to report
>> such situations to the user in some sensible way), as well as some
>> thinking at the level of the formal spec to make sure that we can make
>> sense out of such possibilities. But if we can figure out how to do it
>> nicely, it would open the door to all sorts of further extensions that
>> people have been asking for for years, like per-directory
>> .unisonignore files.
> 
> I agree it would be a more general approach, but it requires many more
> changes as you said.
> 
> Alan
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers