Closed eblen closed 13 years ago
yes we should just ignore the binary issue remotely for now. Unless we have some idea how we can do it. But I like that it is in the same function. Maybe we can just let the function autodetect whether this is a remote or local path and in one case just ignore the binary issue. I like that better than that the caller has to have this logic (e.g. by calling only one or 2 functions depending on whether it is local or remote).
On Thu, Jun 9, 2011 at 5:20 PM, eblen < reply@reply.github.com>wrote:
See comments for bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=348939
This is non-trivial, because we need to refactor the code a little, separating out file matching and binary file filtering, and of course filtering binary files remotely is not easy.
Reply to this email directly or view it on GitHub: https://github.com/rolandschulz/PTP/issues/45
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309
Done in commit 21c6af7ff8a3a3629c97443f8fc220477c260e59 We still use only one function, but now it is invoked for both directions. To solve the binary file issue, the filter returns false (do not filter) for files not recognized by CDT. Since the filter only inputs file names, it can only look at local files. Thus, remote files are not sync'ed if they have the same name as binary files filtered on the local side, which is fine.
This particular issue is resolved. A complete solution to file filtering, though, will be more complex and involve a mechanism for users to select/unselect files to be filtered.
See comments for bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=348939
This is non-trivial, because we need to refactor the code a little, separating out file matching and binary file filtering, and of course filtering binary files remotely is not easy.