Page 3 of 4

Re: WinMerge 2011

PostPosted: Thu Nov 10, 2011 7:55 pm
by nitnit
Update
I have seen this work in a VirtualBox with Windows 7 Enterprise 90-day Trial 64-bit installed, after manually registering ShellExtensionX64.dll with regsvr32.exe. I have also learned that .hta files execute in 32-bit by default, which is why the setup.hta fails at this task.


I could finally register the shell extensions for win7-x64 with version 0.2011.001.464 setup.wsf (couldn't do it with ver. 0.2011.001.461 setup.wsf).

Also thanks for solving the UNC bug.

I wonder why wont you upload your winmerge2011 to the main site ! I think that this way other users and developers will be aware of it and it will get a lot more testing and feedback.

Thanks

Re: WinMerge 2011

PostPosted: Thu Nov 10, 2011 8:00 pm
by kimmov
nitnit wrote:I wonder why wont you upload your winmerge2011 to the main site !

Because it is essentially Jochen's own rewrite and fork of WinMerge. I don't know how it could be made (in case Jochen is even interested) a mainline version.

Re: WinMerge 2011

PostPosted: Fri Nov 11, 2011 6:43 am
by jtuc
nitnit wrote:I wonder why wont you upload your winmerge2011 to the main site !

This requires permission by project managers. I contacted them couple of weeks ago, and am quite confident that WinMerge 2011 will finally gain their trust. It certainly needs time, especially as WinMerge 2011 deviates from some well-reasoned (albeit not well-agreed) design decisions that had been made for WinMerge 2. (Hint: Read between the lines.)

kimmov wrote:I don't know how it could be made (in case Jochen is even interested) a mainline version.

I thought that's obvious from GNU GPL terms.

Re: WinMerge 2011

PostPosted: Wed Nov 16, 2011 8:31 am
by gerundt
jtuc wrote:This requires permission by project managers. I contacted them couple of weeks ago, and am quite confident that WinMerge 2011 will finally gain their trust.


If you create a public fork with Mercurial or Git at bitbucket.org or github.com it would be much easier for all! All others can see the individual commits you made and could even help you. Only a source code package every few weeks make it not easy to help you with patches. :(

We anyway wanted for the "WinMerge 3" source code to go away from Subversion (and SF.net) to Mercurial or Git. We try Mercurial (with bitbucket) since it is a little bit easier for Windows developers. But Git (with github) is much more powerfull. But both are better then the old way with Subversion!

It would be later very easy to use your own "WinMerge 2011" repository (or a clone) for a "official" WinMerge version!

I only think "WinMerge 2012" would be a better name, since the next year is a more realistic date for a WinMerge version with a "official" stamp. :mrgreen:

Re: WinMerge 2011

PostPosted: Wed Nov 16, 2011 10:20 am
by kimmov
jtuc wrote:
nitnit wrote:I wonder why wont you upload your winmerge2011 to the main site !

This requires permission by project managers. I contacted them couple of weeks ago, and am quite confident that WinMerge 2011 will finally gain their trust.

I have quite a lot to say about this...

What you basically want is we declare your version of WinMerge as "the WinMerge". Meaning the project stoods behind your version and supports it. Now, why would we do that?

What you did is gone totally silent, made huge rewrite without any communication or even hint for us what you were doing. Then you came up with significantly rewritten version and told us "here's my version, you must take this as your version". Don't you see the problem? And you are even continuing this silent development, only offering code drops from your own releases. This is significantly different to how WinMerge has always been developed (after it was released to open source).

I guess the question is who defines what WinMerge is. Quite a lot of that comes to me (who you bypassed totally). And ultimately it is Dean (who you have bypassed totally). What would be our motivation to take your version as ours? Update installers, documentation, web, reply in mailing lists, forums etc etc. Unfortunately this project is not just about the C++ code and WinMerge executable.

jtuc wrote:It certainly needs time, especially as WinMerge 2011 deviates from some well-reasoned (albeit not well-agreed) design decisions that had been made for WinMerge 2. (Hint: Read between the lines.)

Which is why your version strictly speaking can't be official version. It does not work that one developer changes the decisions on his own and then tries to make them part of the official version. It is one developers opinion about the subject. There are millions of users and we don't change design decisions and affect all users because of few loud complainers. That is the fact too many people don't understand, let alone the complainers.

jtuc wrote:
kimmov wrote:I don't know how it could be made (in case Jochen is even interested) a mainline version.

I thought that's obvious from GNU GPL terms.

What GPL says is we are allowed take your code changes which don't alter the license back to our codebase. It just allows us to do it legally. I was referring to all the practical issues in my comment, not licensing issue (which I think is clear).

Re: WinMerge 2011

PostPosted: Tue Nov 22, 2011 3:46 pm
by duncan_lilly
Whatever the politics of this; I'm extremely happy since this build resolves long standing issues with UCS-2 files not getting reported as changed when doing folder compares - hooray! :D

So I hope you guys can sort it out, and in the meantime a huge thank you to Jochen!

Re: Updated Changelog

PostPosted: Wed Nov 23, 2011 4:40 pm
by cecilyen
jtuc wrote:Next version:
• File transform scriptlet to drive XLS2CSV Converter (xls2csv.genxcrowd.com)
• File transform scriptlet to drive Antiword (http://www.winfield.demon.nl)
• Allow file transform scriptlets to show a config dialog prior to comparison
• Add icons to file/folder selection controls (adapted from Takashi's fork)
• Consolidate unicode detection in DetermineEncoding() (file unicoder.cpp)
• Fine-tune UCS-2 detection (in particular, don't assume UCS-2 from BOM only)
• Do text vs. binary classification uniformly for both quick and full compare
• Fix System32 build configuration for stack frames going beyond 4096 bytes


Is there any chance to support diff between two PDF in the next version?
Maybe xdoc2txt can be used here for supporting more format. http://www31.ocn.ne.jp/~h_ishida/xdoc2txt.html

Re: WinMerge 2011

PostPosted: Thu Nov 24, 2011 7:36 am
by jtuc
cecilyen wrote:Is there any chance to support diff between two PDF in the next version?
Maybe xdoc2txt can be used here for supporting more format.

Yes that works nice. I'll drop Antiword and XLS2CSV Converter in favor of xdoc2txt. Thanks for suggesting!

Re: WinMerge 2011

PostPosted: Mon Nov 28, 2011 8:01 am
by nitnit
With recent 2011.001.464 version, on an win7-x64, when trying to compare as Binary (either via the "open" dialog, or shell context menu) I am getting an error message: "Class does not exist"

It works fine on another XP x32 system !

Any idea how to solve this ?

Re: WinMerge 2011

PostPosted: Mon Nov 28, 2011 9:08 am
by jtuc
nitnit wrote:I am getting an error message: "Class does not exist"
This usually happens when Frhed is not installed. 64-bit should be no problem.