Folder comparsion behavior changed

[shikawa]

I update from 2.10.4 to 2.12.x the folder comparsion behavior changed.

If I have subset folder and compare with the full set folder.

In 2.10.4 the win merge only compare the subset folder and the files in the subset. It may content only 254 files.

But 2.12.x the winmerge will compare the full set folder and the files in the full set folder. It may content 124387923 files.

But 124387923 only 254 files need to be compared, others are not exist.

2.12.x will waste much time to compare the files don't exist.

Thanks.

[kimmov]

WinMerge does not compare unique files. It only lists them. And listing them allows user to work with them. Earlier WinMerge versions just didn't show the whole truth to the user.

Yes, it can take longer. But correct and complete results are more important than some more time spent.

[shikawa]

Dear kimmov:

Thanks for your reply.

Could it be a feature which user can disable and enable by their requirement.

Sometime, we don't wan't to list the files in the un-exist folder but some time we need.

ex. patch linux kernel, maybe just fifteen files must be compare. But It take me 10 mimutes for waiting it finished.

Thanks.

Autumn

[kimmov]

I've thought about option. But it seems tricky: how one can know beforehand if unique folders are interesting or not? Sometimes you may know, but what about the cases you don't know?

[hollasch]

I've just updated my copy of WinMerge as well and hit this same problem. For my purposes, I have a collection of files checked out (typically 5 - 15) of a source tree that contains over 130,000 files. I create a sparse tree that contains only the old versions of the files I have checked out. Before this, WinMerge would quickly compare the two trees and I could see the changes I've made so far (and optionally revert/edit changed blocks as needed).

My prior tool version created a copy sparse tree of the files I had checked out, but the problem there was that if I made changes in WinMerge, I'd have to marshal those changes back to my real source tree. I updated my tool to compare the old sparse tree (10 files) against my current tree (130,000 files), and it worked beautifully. Unfortunately, when I updated WinMerge (to get the new feature where WinMerge refreshes on outside changes), my runtime went from under a second to something like five or ten minutes to begin displaying a diff.

We definitely need a switch for this sort of scenario.

[kimmov]

Ok, that is clearly a case where this new behavior sucks.

I'm still sceptic about option - you cannot in general know beforehand "now I'm comparing lots of unique folders". But seems in practice we have no other choice at the moment.

Ignoring also causes problems with copy feature. With current implementation WinMerge knows every file there is, so we can finally add feature to apply file filtering in copying. Which would solve e.g. case of copying folders with .svn folders ignored with filter. If we have ignored unique folders we have no idea if folders contain ignored items. Unless we scan folders before copying which then makes copying slower.

One idea I've been playing with is to make compare show results faster by showing results after top-level folders are compared and then continue compare in background. However that only works with tree-view mode...

[petervanwesten]

I think best is to do the comparing / searching for files based on the options set in the view.

When you only have identical/different files selected, it would not have to know about every unique file in both sides. Just the files that are present in both.

If you then select the unique options, it could do a full search as it is doing by default now.

What adds to the frustration is when you change filter options.
It comes up with a dialog asking to update. But that update is only used for that moment. If you click ok on the 'Open' window after that, the list gets updated again.
With the current slow issue, this takes ages... twice.
So I figured out I just have to click no on the update dialog. But that makes me wonder what the whole use of that dialog is.
You have my vote to through that out.

[matthias1955]

Isn't it enough to know the filename, are we interested in size, encoding ,if it is a binays or text file, ?
If yes, so it will be ok to check the encoding once only, the for the second check it must be same.

[kimmov]

Isn't it enough to know the filename, are we interested in size, encoding ,if it is a binays or text file, ?
If yes, so it will be ok to check the encoding once only, the for the second check it must be same.

No, folder compare does not work like that.

Basic design is to have two threads:

• Collector-thread just gets a list of items in the folders. Nothing else. It uses FindFile() to get directory entries (and gets info like sizes and dates "for free"). It does not (and must not!) open files itself. This thread also does not care about compare method-we always need list of items to compare similar way. Line filters are also applied in this thread.
• Compare-thread does actual comparing, depending on selected compare method. This thread opens files if compare engine requires it. Not all compare engines need or care about file contents.

So the Collector thread does not open files and such has no way to determine binary statuses or encodings. If it would open the files too it would slow down the compare. And it would be sometimes totally unnecessary work and time wasted. As not all compare engines need that info.

For folder compare most important factor for the speed is how much we need to access files. Minimizing filesystem access is key point. Adding file opening to collector thread would be very bad idea.

Consider By Modified date-compare method. It gets all the information it needs from the collector thread. So it doesn't even touch the files in compare thread. Which makes it very fast. Indeed, the "compare" is just comparing two time/size values and the slowest part is collecting that data.

[matthias1955]

But time is lost for uniqe files as the complete function is running!
m_diffFileData.OpenFiles() or plugin opens the files.
So GuessCodepageEncoding() can opens every unique file twice to get encoding info.
Plugins enabled auto, also these are opend for every file.
That takes time to do.
That' why I asked if encoding is needed for unique files. I feel no.
Size date etc we know allready be findfile()

I just checked with stable realse, same.