Synchronize ignores filter for "delete files" option

Help & Support
1

First I'd like to describe my problem: I have two folders, one under Subversion control, one not. The non-versioned folder contains a newer version of this particular directory structure, so by synchronizing I want to overwrite all changed files, to copy all new files and to delete all files that are no longer there. Aditionally, I want the whole synchronize operation to ignore the ".svn" folders in the destination.

SO what I did was activate the delete option in a one-way synchronization and define a location filter to ignore all "*.svn(|*)" locations since the sync filters don't work for folders but only for files. The problem is that Opus still wants to delete all .svn folders and their contents from the destination. It seems that the delete option does not only NOT support folders but it does not use the filters AT ALL.

Am I right with this? Is there a possible workaround for my problem? Should I file a bug report?

2

As far as I know what you want to do is beyond the intended purpose of the synchronize panel. For more complex synchronizing I use xxcopy in a command line script.

3

I had to think a moment about your response, whether I agree or disagree. In conclusion I have to agree AND disagree... It is true that the operation I tried to perform is in fact too complex for the current implementation of the synchronization filter: It just defines the files which are included or ignored from the source, so anything regarding files in the target cannot be done with the current filters. The filter should more precisely be labeled "source filter" or "input filter".

The problem with the current situation is that the "delete files from target that don't exist in the source" switch is a too restricted option. One would at least want to activate another switch to completetly ignore hidden files and folders from the whole sync process. In conclusion, what I really need is an additional "ignore filter" to define files on BOTH source and target side that are COMPLETELY IGNORED in the whole sync process (as in "won't be deleted since they are ignored" and as in "won't reach the input filter since they are ignored").

4

I agree, especially since syncing while ignoring cvs/.svn directories could be quite common.

I'd say it's well worth asking GPSoft if the filtering could be improved to work better in this situation.

5

The acknowledgement mail for my ticket was cropped at the end so if the end didn't reach GPSoft it is posted here for the sake of completeness:

I'd like to request an improvement for the synchronize feature of Opus. This request stems from the thread at

[Synchronize ignores filter for "delete files" option)

Synchronization is virtually unusable when syncing between a folder under version control (SVN/CVS) and a non-versioned folder containing almost the same file and directory structure. The problem is that it's impossible to exclude the .svn folders and their contents from the whole synchronization process. Opus wants to delete all of them if the "delete files from target that are not in the source" is activated. This conflicts with the need to activate this option to truly synchronize the folder with a newer version where some files might be removed and should also be removed from the target but the .svn folders should of course NOT be removed.

Suggested solution: Relabel the current filter to "source filter" and add a new "target filter". The source filter selects or excludes files that are to be comapared with files in the target. The target filter does the same with source and target swapped. Only files passing both filters are compared.

Alternatively, add something like the "subcondition" feature inside the filter definition that allows to define whether this part of the filter should be used for "source", "target" or "both" sides, with the main node defaulting to "source" to keep it compatible.

Additionally, the "delete files from target that are not in the source" should be changed to only do this if the files are not EXPLICITLY excluded from the synchronization through a target filter.

Hint: This in connection with the now available symmetric filtering should allow to keep the "delete" option selectable when using two way compare (where the currennt filter behaviour seems to be "both"). But: Would be tricky to understand => expert mode?

Returning to the above mentioned subversion problem, one could define a target filter to exclude all files with a "*.svn(|*)" from the synchronization and activate the delete option.

External reference: My goal is to implement the svn "best practice" for importing a so-called "vendor drop" using Opus. This practice is detailed in

svnbook.red-bean.com/en/1.1/ch07s05.html

and the "svn_load_dirs.pl" script that is introduced on that page implements a solution for the problem that is non-intuitive, non-interactive and poorly working on Windows (in fact I hate having Perl on my machine just for such a stupid little script).

6

I don't understand where the need for source/destination filters comes from, or really how they would work. If you ignore something in only one side of the sync then how can you compare it to decide whether to copy it (or copy over it, depending on which side we're talking about)?

The .svn directory problem would be fixed just by having the "delete what isn't in source" option ignore things which don't match the existing filter, right?

7

First of all: I shouldn't write posts after 3 in the night. I shouldn't write posts after 3 in the night. I shouldn't write posts after 3 in the night.

Now to clear things up: First some name definitions: There are "destination only" files (DO), "source only" files (SO), "source and destination" files (SD) and source files (S:=SO+SD). I (wildly guessing) think that the current implementation of the synchronization process is split up into two stages: In the first stage Opus scans source and destination (I guess this because flat views are created for both sides prior to the compare). During this scan all files are already "presynced": If the delete option is activated, then all DO files are directly put onto the delete list. All S files are filtered and if they pass, then SO files are directly put onto the copy list. Only SD files are put onto the compare list and reach the second stage. In the second stage all files from the compare list are compared using the requested method. If the source differs from the destination then the file is added to the copy list.

What you are suggesting is to also filter the DO files using the SAME filter as the S files. What I am suggesting is for the user to be able to define DIFFERENT filters for S and DO files. This way, the filters can be SIMPLER and logically seperated: If I sync an unversioned folder into a versioned folder, then I need the path check "nomatch *.svn(|*)" only for the DO files and any "normal" filter rules are just needed for the S files. Depending on how complicated the filter is then this seperation might also be important performance-wise.

In conclusion this leads to an additional (optional) "delete filter" that is applied to the DO files and has to be passed if the file will be deleted. It does not lead to all DO files being filtered through the regular (and possibly much more complicated) filter.