Basic questions

[kimmov]

I've been silent for last two months. Mostly because I've been busy with things outside WinMerge. I haven't had time to spent for WinMerge. Second reason is I've realized that when I (hopefully it is really we later on) start rewriting lots of things from scratch I really don't want to repeat the mistakes that lead to current mess. To be able to avoid mistakes one must know what those mistakes are. So I've tried think a bit about these mistakes and how to avoid them. Some of the mistakes are subjective (some can call them as features too). So here comes my initial list. Not in any particular order.

• no unit testing. WinMerge development started (and was most active) when nobody really know/talked about unit testing. I thought we could add them later on. But it seems people simply are not interested in that if it is just additional work they need to do.
  Unit tests must be part of the required implementation (and patch) not something that can be added later on.
• diff integration through (whole files loaded to) buffers. This causes lots of trouble. It limits file size, causes all kinds of complexity and bugs.
  Not sure yet how to really do this - and this will be important decision. Possibly we should at least try to handle files as streams when interfacing with diff. Unicode conversion might make this interesting though.
• interfacing / implementing other diff methods. It is simple fact we need different methods for different needs. Currently we allow switching method for folder compare. But file compare is always diff. Which causes weird results when file compare and folder compare give different results. This must be clarified. Of course it does not make sense to try to compare by date or size in file compare. But what about byte per byte compare for file compare? Perhaps diffs line-based results should be just one special case? In some cases the byte compare is more useful than line compare.
• update the GUI. Current GUI is from Win 95/98 era. Does really not fit to Vista/Windows 7 world.
• less frameworks and libraries to use. QT provides replacements to some of libraries we use. Use QT whenever possible.
• re-think folder- and filecompare relation. Does folder-compare really own filecompare windows opened from it?
• filtering is very central feature not something added above other things. Filtering can dramatically reduce compare times and help users to see the important changes. For users it is very important to see two important changes instead of hundreds of uninteresting ones. Filtering must be easy, fast and obvious to use.

[matthias1955]

Kimmov wrote:
no unit testing.

agree, it's amust.

Kimmov wrote:
diff integration through (whole files loaded to) buffers.

that' and filtering is our main problem. We may check size if HDD is needed or we can use RAM for faster speed.

Kimmov wrote:
Which causes weird results when file compare and folder compare give different results.

Full and quick can give diff result, that's ok. But full and filecompare must be same.

Why it's not?
we don't support fileconvert in folder compare, so it is possible we have diffent fileformat to compare.
So takeing care for same support of filehandling should solve that problem.

[kimmov]

Kimmov wrote:
diff integration through (whole files loaded to) buffers.

that' and filtering is our main problem. We may check size if HDD is needed or we can use RAM for faster speed.

Using mass storage would kill our performance. You must remember we aren't talking just only "normal desktop pc with fast local disk". "Mass storage" could be slow flash, it could be even remote disk in some SAN system etc.

Kimmov wrote:
Which causes weird results when file compare and folder compare give different results.

Full and quick can give diff result, that's ok. But full and filecompare must be same.

Why it's not?
we don't support fileconvert in folder compare, so it is possible we have diffent fileformat to compare.
So takeing care for same support of filehandling should solve that problem.

I don't understand what you are trying to say. User does not think "now it is quick compare and now it is full compare so I can get different answers". "Are files identical" is simple question but we give too complex answers to users. I don't remember how many times I've been explaining why folder compare and file compare give different results.

Of course there are cases where those more complex answers are required. But it must be user's choice he wants those more complex answers. And we must carefully explain what it means.

[matthias1955]

kimmov wrote: Using mass storage would kill our performance.

under windos we have only 2,7 GB for one session. Means we must use HDD etc for big files even we slow down!

kimmov wrote:I don't understand what you are trying to say.

the file convert (to UTF8) is missing in foldercompare, that's the main reason we get diff ansers. As on UTF-16 etc no filter and some compare options are/can not working as expected.

Full-Quick:
maybe we have to give an other answer in case of a diff, 'can't compare in quick mode', in case of diff codings etc.

[kimmov]

I'm simply not interested about such technical details at this point. They are simply meaningless.

[kimmov]

About memory: I've no idea where you've got that 2.7 GB - but that is not even correct. In 32-bit Windows you can get at max 2 GB virtual memory for process (some server versions allow 3 GB). Now, that virtual memory is disk-backed so you will end up to having data in disk even though it "looks to be" in memory. So what's the point after all... What about all other operating systems? And 64-bit operating systems having "unlimited" memory space? So thinking about any memory restrictions is not useful.

To solve the problem we must use streams or split the data to parts. And diff already supports streams as I wrote in my first message. Using streams mean we can't do some things. So the splitting must be considered too. But that is also non-trivial with diff.

I want to use diff instead of some new algorithm. Lots of people work with source code and version control systems which use diff to generate their patches and differences. Compatibility with that is a big advantage. We can have alternative diff algorithms too (if somebody wants to implement them) but diff is a must.

[matthias1955]

kimmov wrote:
To solve the problem we must use streams or split the data to parts.

that's hat I taking about.

[gerundt]

update the GUI. Current GUI is from Win 95/98 era. Does really not fit to Vista/Windows 7 world.

Sounds good!

less frameworks and libraries to use. QT provides replacements to some of libraries we use. Use QT whenever possible.

Definitely! It is not trivial to compile the WinMerge. But unfortunately I don't get QScintilla2 to run at my machine. So even WinMergeQT is not so easy.

re-think folder- and filecompare relation. Does folder-compare really own filecompare windows opened from it?

This is a thing I don't like at WinMerge from first day I use it! The empty folder-compare window looks like a "bug" and is really confusing, if you want only compare files...

[kimmov]

less frameworks and libraries to use. QT provides replacements to some of libraries we use. Use QT whenever possible.

Definitely! It is not trivial to compile the WinMerge. But unfortunately I don't get QScintilla2 to run at my machine. So even WinMergeQT is not so easy.

What kind of problems you have?

I stopped the WinMergeQT work in Bitbucket once I realized we must be able to support older versions of QScintilla coming with different Linux distributions. I then started thinking good ways to do that and run out of time with all that. It may mean we can't use much of the higher level API but only the lower level API. Which of course makes lots of things harder to do.

re-think folder- and filecompare relation. Does folder-compare really own filecompare windows opened from it?

This is a thing I don't like at WinMerge from first day I use it! The empty folder-compare window looks like a "bug" and is really confusing, if you want only compare files...

I never really liked this myself. But people implementing it thought it was a good idea and it was better to have something than nothing. One thing this "relation" gives us is we can update folder compare status when we save changes in file compare. But of course that should be done differently...

[gerundt]

What kind of problems you have?

QT Creator just say:
winmergeqt.exe exited, return value -1073741511

Visual Studio say:
Entry point of procedure "_Z11qUncompressPKhi" not found in DLL "QtCore4.dll".

The QSinctilla2 examples are also not working, so I think it is problem with my QScintilla build.