Comparing source trees
Moderators: Hacker, petermad, Stefan2, white
Comparing source trees
I often have to compare 2 trees of source code. This means in most cases some search term is to be found in both trees. Files which contain the term must be compared if they are different. It sounds like a task for sync. dirs but it doesn't have support for search terms.
So I usually perform two equal searches (with different base paths of course) on both sides and get a result list on both sides. When the list is quite long it's often difficult to find the files with the same name.
In many cases I have to refine the search which means performing _both_ searches again.
Any ideas? Or maybe this is something that could be improved?
So I usually perform two equal searches (with different base paths of course) on both sides and get a result list on both sides. When the list is quite long it's often difficult to find the files with the same name.
In many cases I have to refine the search which means performing _both_ searches again.
Any ideas? Or maybe this is something that could be improved?
- ghisler(Author)
- Site Admin
- Posts: 50918
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Well, the best solution would be to allow saved searches in the sync dialog. Unfortunately there are several problems:
1. Since 2 files have to be searched, time-dependent filters like "max 1 hour old" could return different results for 2 identical files.
2. The filter could return true for the left and false for the right file because only one contains the searched word. Should the pair be included or not in this case?
3. Comparing with FTP/Plugins/Archives: These locations do not work with content plugins.
1. Since 2 files have to be searched, time-dependent filters like "max 1 hour old" could return different results for 2 identical files.
2. The filter could return true for the left and false for the right file because only one contains the searched word. Should the pair be included or not in this case?
3. Comparing with FTP/Plugins/Archives: These locations do not work with content plugins.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
2ghisler(Author)
I guess a special indicator would be extremely helpful to illustrate to the user that the filter is only matched on one side. It would be of course only visible if it makes sense.
Here is a first idea. I guess there are better ways to illustrate it:
[img]http://fs1.directupload.net/images/150814/ku5jn6oq.png[/img]
I guess that's always the problem when 'ignore date' isn't checked.1. Since 2 files have to be searched, time-dependent filters like "max 1 hour old" could return different results for 2 identical files.
Yes absoutely! For my task I'm also interested when the term is only matched for one side. The file on the side where the term isn't found is likely the side where something is missing and I have to perform a compare files operation on them.2. The filter could return true for the left and false for the right file because only one contains the searched word. Should the pair be included or not in this case?
I guess a special indicator would be extremely helpful to illustrate to the user that the filter is only matched on one side. It would be of course only visible if it makes sense.
Here is a first idea. I guess there are better ways to illustrate it:
[img]http://fs1.directupload.net/images/150814/ku5jn6oq.png[/img]
Downloading the dirs from the server temporary is the only way to fully support it. Otherwise you'll have to display a warning or so.3. Comparing with FTP/Plugins/Archives: These locations do not work with content plugins.
Perhaps some content plugin with compare function for sync tool may help: it checks equal files w/o term and compares files with the term. It may display different icons depending on compare results (term is found in both files, files different; term is only found in left/right file etc). The only problem is setting the term because there is no initialization function for compare plugins (so plugin would have to use some ways of first compare detection in order to ask information).
Content plugins lack notification function anyway: start multi-rename, end multi-rename, start enumerating folder contents, end enumerating folder, start sync compare, end sync compare... With such function plugin could display a dialog asking for terms to be searched or reset some counters. E.g. file system plugins have FsStatusInfo function that is called to notify plugin about some event with path information.
Content plugins lack notification function anyway: start multi-rename, end multi-rename, start enumerating folder contents, end enumerating folder, start sync compare, end sync compare... With such function plugin could display a dialog asking for terms to be searched or reset some counters. E.g. file system plugins have FsStatusInfo function that is called to notify plugin about some event with path information.
2MVV
But this is also an argument against solving my task using a saved search. This is still to cumbersome. I guess I want to enter the rules directly.
Of course I thought about that too. But you wrote it. There is no way to input terms to content plugins. In some cases this is more or less acceptable, but here it's deadly.Perhaps some content plugin with compare function for sync tool may help: it checks equal files w/o term and compares files with the term. It may display different icons depending on compare results (term is found in both files, files different; term is only found in left/right file etc). The only problem is setting the term because there is no initialization function for compare plugins (so plugin would have to use some ways of first compare detection in order to ask information).
But this is also an argument against solving my task using a saved search. This is still to cumbersome. I guess I want to enter the rules directly.
Well, it may be done e.g. when Shift is down and plugin is called (it may help to detect first comparison). But it would be much better to have event notifications.Lefteous wrote:There is no way to input terms to content plugins.
Will it show corresponding files on target panel if they don't contain text?ZoSTeR wrote:FYI: You can do that with Beyond Compare. Folder Compare -> Filters -> Other Filters -> Not Containing "xyz"
Yes, and actually there is a way by using my PCREsearch plug-in.MVV wrote:Perhaps some content plugin with compare function for sync tool may help
Define a new field with type 'file compare' (best use PCREsearchConfig).
RegEx:
Code: Select all
(?s)\A(?=.*?MYTERM).*+|\A
Field name whatever you like.
That very RegEx means:
By using a positive Lookahead Assertion we make sure that we'd compare files only when they contain "MYTERM",
which also works if the term is only found on one side.
That "void" alternation kicks in when the term is found on neither side,
and makes sure that the plug-in returns the files as equal in such case (that's why you have to enable void matches to pass),
because otherwise the plug-in would signal TC that it can't compare the files (no match = no statement) and TC would either try the next compare plug-in
or do a binary compare on it's own.
Now define a new compare filter with that plug-in field you just created (remember you need to use cm_UnloadPlugins after altering the plug-in config).
So what you'll see after the compare:
- Term found on one side only: unequal icon
- Term found on both sides and files compare not equal: unequal icon
- Term found on both sides and files compare equal: the plug-in's equal icon (red PCRE above the equal sign)
- Term found on neither side: the plug-in's equal icon
For comparing larger files (default 10 MiB halfed = 5 MiB for each file) you might want to increase read memory, to avoid false multiple matches (due to singleline mode).
Note: compare equal also works for recoded files (e.g. one side Unicode, the other ANSI, etc.)
I know, PCREsearch needs to be set up every time you want to change the search term,
but if you use the same search several times it'd be not that bad, plus you can define several fields "in advance" (e.g. for common search terms).
So there's now another reason for finally implementing an on-the-fly wdx plug-in setup.

Edit:
I updated the expression, since it didn't work well for larger files, due to possessive quantifiers.
Of course it should also work without lookahead:
Code: Select all
(?s).*?MYTERM.*+|\A
Code: Select all
(?s-i).*?MYTERM.*+|\A
Last edited by milo1012 on 2015-08-22, 18:34 UTC, edited 2 times in total.
TC plugins: PCREsearch and RegXtract
Yes but for this task there would have enter a plugin configuration.I know, PCREsearch needs to be set up every time you want to change the search term,
but if you use the same search several times it'd be not that bad, plus you can define several fields "in advance" (e.g. for common search terms).
So there's now another reason for finally implementing an on-the-fly wdx plug-in setup. Wink
I'm still convinced that this is a filter thing as Ghisler wrote. The new feature would handling items which are only found on one site.