Comparing source trees

English support forum

Moderators: Hacker, petermad, Stefan2, white

Post Reply
User avatar
Lefteous
Power Member
Power Member
Posts: 9537
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Comparing source trees

Post by *Lefteous »

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?
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50918
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

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.
Author of Total Commander
https://www.ghisler.com
User avatar
Lefteous
Power Member
Power Member
Posts: 9537
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

2ghisler(Author)
1. Since 2 files have to be searched, time-dependent filters like "max 1 hour old" could return different results for 2 identical files.
I guess that's always the problem when 'ignore date' isn't checked.
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?
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.
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]
3. Comparing with FTP/Plugins/Archives: These locations do not work with content plugins.
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.
User avatar
MVV
Power Member
Power Member
Posts: 8711
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

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.
User avatar
Lefteous
Power Member
Power Member
Posts: 9537
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

2MVV
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).
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.

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.
User avatar
ZoSTeR
Power Member
Power Member
Posts: 1052
Joined: 2004-07-29, 11:00 UTC

Post by *ZoSTeR »

FYI: You can do that with Beyond Compare. Folder Compare -> Filters -> Other Filters -> Not Containing "xyz"
User avatar
MVV
Power Member
Power Member
Posts: 8711
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Lefteous wrote:There is no way to input terms to content plugins.
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.
ZoSTeR wrote:FYI: You can do that with Beyond Compare. Folder Compare -> Filters -> Other Filters -> Not Containing "xyz"
Will it show corresponding files on target panel if they don't contain text?
User avatar
ZoSTeR
Power Member
Power Member
Posts: 1052
Joined: 2004-07-29, 11:00 UTC

Post by *ZoSTeR »

MVV wrote:Will it show corresponding files on target panel if they don't contain text?
Yes. They're colored differently.
User avatar
milo1012
Power Member
Power Member
Posts: 1158
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 »

MVV wrote:Perhaps some content plugin with compare function for sync tool may help
Yes, and actually there is a way by using my PCREsearch plug-in.

Define a new field with type 'file compare' (best use PCREsearchConfig).
RegEx:

Code: Select all

(?s)\A(?=.*?MYTERM).*+|\A
[x] Empty matches pass through
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
In short: all file pairs where the term is found and which don't compare equal are marked as unequal, everything else won't be.

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
And remember to enable case sensitive matching, if you need it:

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
User avatar
Lefteous
Power Member
Power Member
Posts: 9537
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

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
Yes but for this task there would have enter a plugin configuration.

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.
Post Reply