winmerge-development — For discussing development

[Winmerge-development] Plugin Dev in .Net / C#, file encoding woes, future of plugin system

[Tao K. <ta...@kl...>]

Hi,

Sorry I'm posting out of the blue - I only just joined the mailing list and
wanted to get this stuff out while it's still fresh on my mind. (and the
forum seems to be broken, or at least timing out for me)

This weekend I added a WinMerge plugin to my T-SQL Formatter project, and it
turned out to be a reasonably painful process, for two main reasons:

   1. I couldn't figure out how to get Winmerge's COM-loading code to
   recognize my .Net DLL with TLB type library file (registered through RegAsm)
   - I suspect it can't be done, but would love to hear otherwise! (I ended up
   creating a VB6 proxy COM object just to load my .Net code)
   2. As far as I can tell the only way to visibly pre-format code is with
   the "BUFFER_PACK_UNPACK" and "FILE_PACK_UNPACK" plugin types, but neither of
   these has access to a text stream / string, they both get raw bytes in
   whatever encoding the source is, and therefore have to implement their own
   detection; On top of that, the "BUFFER_PACK_UNPACK" type seems to have some
   strange behaviour where the BOM detection happens before the plugin is
   called, but afterwards there is still some sort of later encoding detection
   (if you add or remove a BOM all hell breaks loose, but if you just change
   the BOM to indicate a different encoding like UTF-8 instead of UTF-16BE,
   it is handled gracefully)

I saw in the wiki that you guys were at one point planning on scrapping the
current plugin system entirely (http://wiki.winmerge.org/wiki/Plugins_System),
but it's now version 2.12.X and it hasn't gone - is the plan still to get
rid or it? (in 3.X?) What will follow? If it's any help, for my purposes a
command-line pre-comparison call to an arbitrarily defined command would be
a nice simple solution - and apparently another popular comparison tool,
Beyond Compare, supports exactly that. So a "plugin" developer simple
creates a command-line preprocessor program which takes a source and
destination filename, much like the current "FILE_PACK_UNPACK" plugin type.
Nice-to-haves would include an option to get a known-encoding source file
instead of the raw original, and of course the current "unpack vs prediff"
distinction, affecting whether modifications are displayed to the end-user
or not.

If it's of any interest, the plugin I created is in my "Poor Man's T-SQL
Formatter" project, at:
http://www.architectshack.com/PoorMansTSqlFormatter.ashx
I haven't tested it extensively (I'm not sure how the ADODB / MDAC 2.8
dependency is going to work out for most people, don't think it will support
64-bit, etc), but at least it seemed to work on a couple other systems I
tried it on. I'd love a second opinion or feedback if it's of any value to
anyone here.

Thanks,
Tao

[Winmerge-development] Need Help

[M V D. <mvd...@gm...>]

Hi,

I have recently joined Winmerge project and would want to contribute in my
free time. I have some working knowledge in c/c++ on windows.
As I am new to this project, I would like to have one of the
active developers to be my mentor.
Any initial help in picking up bugs(related to c/c++) and some pointers in
solving them would be greatly appreciated.

Looking forward for good support.

Regards,
-MVD

Re: [Winmerge-development] [Winmerge-dev] WinMerge 3

[Kimmo V. <ki...@wi...>]

Hi,

> So looking at QScintilla, it looks like the right stuff is there. Looks
> like we can set the selection, style the text based on line number, and
> cut and paste text, etc. I'm new to this, so I need to figure out how to
> implement the split window and synchronized scrolling. Looks like
> QSplitter and QScrollArea should do the job...

I did simple QSCintilla test earlier at:
https://bitbucket.org/kimmov/winmergeqttest/

The basic stuff is easy with the higher level API (as seen from above test).

The problem arises when you need more than the basic stuff. You need to 
fall down to the lower level messaging API. And that is not sweet to 
use. It is kind of working with some device driver, you send bunch of 
constant to the component, one being message number, then parameters 
etc. Kind of old good days of Win32 API...

Just look at this (horrible) documentation:
http://www.riverbankcomputing.co.uk/static/Docs/QScintilla2/classQsciScintillaBase.html

Another issue is we can't even use all of the higher level API if we 
want to support linux distros with older QScintilla version. Which got 
me distracted from my tests earlier.

Compare above e.g. to this Qt Creator'a text editor API:
http://qt.gitorious.org/qt-creator/qt-creator/blobs/master/src/plugins/texteditor/basetexteditor.h

But then I can't say how much work would be needed to use Qt Creator's 
editor plugins. And how much modifications would be needed to those plugins.

Regards,
Kimmo

[Winmerge-development] Disable Piwik web analytics service

[Tim G. <ti...@ge...>]

Hi list,

we added once the piwik web analytics service from SourceForge.net to 
our website. The software is nice (even if the SF.net app version is not 
perfect). But we never use it really intensely. I sometimes login and 
look at the nice graphs, but nothing more. So did we really need it?

http://sourceforge.net/apps/piwik/winmerge/

I think we should disable it at SF.net and drop the tracker code from 
the website and save the visitors 500ms at the page load.

What do you think?

Greetings,
Tim

Re: [Winmerge-development] [Winmerge-dev] WinMerge 3

[Dean G. <gr...@ya...>]

Hi Kimmo,
So I'm starting to look at the editor piece, and have some  
observations. First, it seems like the QTextEditor component in Qt3  
was much more straightforward to use with functions like lines(),  
text(i), etc, but the component looks a lot less straightforward in  
Qt4. Seems like we'd have to go into the QTextDocument and then into  
the blocks to get things done. Yuck.

So looking at QScintilla, it looks like the right stuff is there.  
Looks like we can set the selection, style the text based on line  
number, and cut and paste text, etc. I'm new to this, so I need to  
figure out how to implement the split window and synchronized  
scrolling. Looks like QSplitter and QScrollArea should do the job...

What were the things you didn't like about the component? Unless there  
are some showstoppers, I may start prototyping some basic functionality.

Regards,
Dean

Re: [Winmerge-development] [Winmerge-dev] google-diff-match-patch

[Kimmo V. <ki...@wi...>]

Hi!

> I recently come across the "google-diff-match-patch" project:
> http://code.google.com/p/google-diff-match-patch/

Interesting! Looking at the API doc it provides some nice features for 
different kind of diffs.

> "The Diff Match and Patch libraries offer robust algorithms to perform
> the operations required for synchronizing plain text. [...] Currently
> available in Java, JavaScript, C++, C#, Objective C, Lua and Python.
> Regardless of language, each library features the same API and the same
> functionality. All versions also have comprehensive test harnesses."
>
> Would this maybe an alternative for "LibXdiff"? It seems more active as
> LibXdiff.

Definitely something worth looking at. API at least seems much easier 
and simpler.

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] WinMerge 3

[Kimmo V. <ki...@wi...>]

Hi,

> I think that in order to
> spark interest in development, people need a compelling reason to
> devote their scarce time. Speaking personally, I like WinMerge, and
> use it every day. Would a sexier version of the product be nice?
> Maybe. Do I need it? No.

This is very true too. Hard-core old timers have used to current way of 
working, current interface etc. It works, don't fix it. However, if 
somebody is looking for compare tool and looks at screenshots, is he/she 
likely to choose WinMerge? Or when somebody shows current user how nice 
looking interface other tool has, is current user likely to try the new 
tool? So we have lots of users, but probably not many new users. And 
current users might be looking to other tools after running into 
problems/bugs with current tool.

> The one piece that has me interested is the notion of being able to
> use a common product for Win/Mac/Linux.

> I can relate to the notion of Qt being a relief; I still maintain some
> VB code and recently ported it to C#. Like .net or not, it was like
> stepping out into the sunlight after a cold winter. Everything is just
> easier, makes more sense, makes me more productive. I'm sure Qt is
> similar.

I've actually seriously considered few times how WinMerge would work if 
implemented in .Net. There are not many really performance-critical 
parts and that could be pretty easily put into native libraries. If we 
would be doing Windows-only WinMerge I'd definitely want to do it with .Net.

> As I said previously, I'm willing to take a piece of the project, but
> it will take time. If everyone is serious about this, then we need to
> start defining some basic needs and divvy them up. I'm not totally
> thrilled about learning yet another framework (sure would be nice if
> Java could work), but if Qt is the consensus then let's get it going.

At the end what I really care is we must be able to do some 
file/directory level operations at lower level C/C++. Possibly some 
diffing / diff handling too. Because of performance. We may need to 
handle tens or hundreds of thousands of files in directory compare. And 
tens of gigabytes data in file compare. And more abstracted layers 
usually are not very good at that... Above that, filtering, GUI etc I 
don't care so much what language is used. I like Qt because it offers 
the full scale from rather low level (fast implementation) to GUI. So no 
need to mix different frameworks or APIs.

> We need some initial basics like:

I actually had one new idea during the weekend. What if we made WinMerge 
architecture a 'pipe' where each part of the pipe is a (Qt-) plugin. So 
we'd have parts like:
* directory discovery - finds the files and subdirectories from given 
directory
* directory filtering
* compare - outputs diffs of items
* diff processing
* diff visualization (GUI)

This is just the first sketch but you probably get the idea. Having all 
these being plugins mean we can have different implementations for each, 
based on need. Need FTP support - implement plugin getting files through 
FTP!. Need custom filtering - implement plugin for that. Need XML 
compare - implement plugin...

We don't need to right away start writing only plugins but we should 
keep this in mind when structuring the code. So we can at least later on 
make it plugins.

> * File diff/editor view (do we need to prototype this before we start
> on anything else?)
Good question. I quess we could start with simple rich text viewer. But 
how to show the 'diffs' I've no idea yet. Depends a lot of course about 
used editor component...

> * LibXdiff interface layer
I have basics set up already. But of course needs to be expanded, 
perhaps considering the above plugin-suggestion.

> * Plugin architecture? Do we want to go here?
Using Qt-plugins "internally", IMO absolutely. Offering "plugins" as in 
WinMerge 2.0 for expanding WinMerge. If done properly (see my suggestion 
above) it would not be much extra work and would make WinMerge really 
flexible.

> Kimmo, do you have any ideas on what you'd like to work on? Let's
> start talking about some specific directions so we can split up some
> work.

I think I could start setting up very basics for the plugin 
architecture. And starting with directory compare basics (reading 
structure, attribute (size/date) compare).

Regards,
Kimmo

[Winmerge-development] google-diff-match-patch

[<ti...@ge...>]

Hi list,

I recently come across the "google-diff-match-patch" project:
http://code.google.com/p/google-diff-match-patch/

"The Diff Match and Patch libraries offer robust algorithms to perform
the operations required for synchronizing plain text. [...] Currently
available in Java, JavaScript, C++, C#, Objective C, Lua and Python.
Regardless of language, each library features the same API and the same
functionality. All versions also have comprehensive test harnesses."

Would this maybe an alternative for "LibXdiff"? It seems more active as
LibXdiff.

It uses the "Apache License 2.0", but this should be no problem, if we
use GPL 3 for WinMerge 3 (and since we start from scratch, it should no
problem to switch to GPL 3).

"The Apache Software Foundation and the Free Software Foundation (FSF)
agree that the Apache License 2.0 is a free software license, compatible
with version 3 of the GNU General Public License (GPL). [...] It should
be noted, however, that there is a one-way incompatibility between the
Apache version 2 and GPL version 3 licenses, in that GPL version 3 code
cannot be included in an Apache project without activating the
requirement that the entire project be relicensed under the GPL version
3."

http://en.wikipedia.org/wiki/Apache_License#GPL_compatibility

What do you thing? (Remember: I had no idea about the view of a C++
developer! *g*)

Greetings,
Tim


___________________________________
NOCC, http://nocc.sourceforge.net

Re: [Winmerge-development] [Winmerge-dev] WinMerge 3

[Dean G. <gr...@ya...>]

Hello,
I think the challenge we face with WinMerge in general is that a) it  
is a mature product that does mostly what we need it to do, and b) we  
are all so busy that we contribute to the project to the extent that  
we need things done, which is not often. I think that in order to  
spark interest in development, people need a compelling reason to  
devote their scarce time. Speaking personally, I like WinMerge, and  
use it every day. Would a sexier version of the product be nice?  
Maybe. Do I need it? No.

The one piece that has me interested is the notion of being able to  
use a common product for Win/Mac/Linux. I like our usage paradigm, and  
it would make me more productive on all my projects if I had a cross  
platform version. Again speaking personally, I don't need to compare  
archive contents, binary contents, etc... I just need a simple tool to  
compare code branches and interact with source control (it would be  
excellent if I could do an Hg commit on the current set of merged  
files, for example).

I can relate to the notion of Qt being a relief; I still maintain some  
VB code and recently ported it to C#. Like .net or not, it was like  
stepping out into the sunlight after a cold winter. Everything is just  
easier, makes more sense, makes me more productive. I'm sure Qt is  
similar.

As I said previously, I'm willing to take a piece of the project, but  
it will take time. If everyone is serious about this, then we need to  
start defining some basic needs and divvy them up. I'm not totally  
thrilled about learning yet another framework (sure would be nice if  
Java could work), but if Qt is the consensus then let's get it going.  
We need some initial basics like:

* Class layout
* Basic GUI
* Directory comparison view
* File diff/editor view (do we need to prototype this before we start  
on anything else?)
* LibXdiff interface layer
* Plugin architecture? Do we want to go here?

Kimmo, do you have any ideas on what you'd like to work on? Let's  
start talking about some specific directions so we can split up some  
work.

Regards,
Dean

On Mar 10, 2011, at 11:14 AM, Kimmo Varis wrote:

> Hi all,
>
> it has been quiet with the WinMerge 3 effort in past months. No  
> commits
> or anything.
>
> I started looking at this again, from a new point of view. Earlier we
> were thinking too much of "cloning" current WinMerge to new toolkit  
> and
> environment. Which, while doable, is inefficient and hard to do. I  
> guess
> the main idea was we could use existing code. But more I think about  
> it
> less I want to use the existing code!
>
> We should use just the good ideas and knowledge from the WinMerge 2.x
> and write the code again. Why not re-use lots of working code? Mostly
> because the code is written for one specific environment (Windows 9x/ 
> Nt
> and some support for later versions) and for MFC toolkit. Converting
> most of that to the new cross-platform enviroment and new toolkit is  
> not
> easy and probably leads to all kinds of hacks (above all the current
> hacks). So we just get even worse code.
>
> I know I'm balanced (fan of Qt) but sometimes it is just amazing how
> easy things are with it (remembering it is C++). See this commit I did
> couple of days ago:
> https://bitbucket.org/grimmdp/winmerge/changeset/dd7549327cee
>
> There it is, basic idea of dir compare, done in 15 minutes. Of course
> most of the logic is missing, threading is missing etc. But getting
> listing of files in two folders and comparing them is there. In  
> WinMerge
> 2.x we spent months for that. Of course there is some performance
> penalty in using higher level Qt classes. But does somebody notice?  
> And
> there are certainly possibilities for optimizing it later on.
>
> But my point is - by using Qt classes we can do much of the WinMerge  
> 2.x
> things much easier now. And lots faster. I bet what Qt already  
> offers is
> enough in most places, like threading, GUI, XML handling, regular
> expressions etc etc.
>
> There are couple of challenges though:
> - the file compare diff handling
> - the file compare GUI
>
> LibXdiff produces nice diffs but they are different (Git-style) from
> what difftools produced. And there is no whitespace ignore etc. So we
> need some logic layer above LibXdiff. I can forget things like writing
> difftools-compatible patches for now on.
>
> File compare GUI is challenging. There is simple editor with Qt but we
> need much more. Scintilla and its Qt bindings have been discussed. But
> I'm not very happy about it. I think most things we want to do are
> doable. Remembering we don't need to do everything exactly like in
> WinMerge 2.x.
>
> Few days ago I got a new idea about using QtCreator's editor etc
> plugins. QtCreator is very nice development IDE and basically  
> everything
> in it is a Qt plugin. Editor is code editor so it supports many  
> features
> we want.
>
> Which got me thinking about WinMerge 3 architecture. What if we did it
> similar way to QtCreator and heavily use Qt's plugin architecture...
> Perhaps not in level that everything is plugins but things like
> filtering, version control support, archive support etc. That is
> something I really need to think about more...
>
> Following days I will continue working with very basic folder  
> compare. I
> hope to get some very simple GUI done too. And start testing some  
> new ideas.
>
> Regards,
> Kimmo
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Winmerge-dev mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winmerge-dev

[Winmerge-development] WinMerge 3

[Kimmo V. <ki...@wi...>]

Hi all,

it has been quiet with the WinMerge 3 effort in past months. No commits 
or anything.

I started looking at this again, from a new point of view. Earlier we 
were thinking too much of "cloning" current WinMerge to new toolkit and 
environment. Which, while doable, is inefficient and hard to do. I guess 
the main idea was we could use existing code. But more I think about it 
less I want to use the existing code!

We should use just the good ideas and knowledge from the WinMerge 2.x 
and write the code again. Why not re-use lots of working code? Mostly 
because the code is written for one specific environment (Windows 9x/Nt 
and some support for later versions) and for MFC toolkit. Converting 
most of that to the new cross-platform enviroment and new toolkit is not 
easy and probably leads to all kinds of hacks (above all the current 
hacks). So we just get even worse code.

I know I'm balanced (fan of Qt) but sometimes it is just amazing how 
easy things are with it (remembering it is C++). See this commit I did 
couple of days ago:
https://bitbucket.org/grimmdp/winmerge/changeset/dd7549327cee

There it is, basic idea of dir compare, done in 15 minutes. Of course 
most of the logic is missing, threading is missing etc. But getting 
listing of files in two folders and comparing them is there. In WinMerge 
2.x we spent months for that. Of course there is some performance 
penalty in using higher level Qt classes. But does somebody notice? And 
there are certainly possibilities for optimizing it later on.

But my point is - by using Qt classes we can do much of the WinMerge 2.x 
things much easier now. And lots faster. I bet what Qt already offers is 
enough in most places, like threading, GUI, XML handling, regular 
expressions etc etc.

There are couple of challenges though:
- the file compare diff handling
- the file compare GUI

LibXdiff produces nice diffs but they are different (Git-style) from 
what difftools produced. And there is no whitespace ignore etc. So we 
need some logic layer above LibXdiff. I can forget things like writing 
difftools-compatible patches for now on.

File compare GUI is challenging. There is simple editor with Qt but we 
need much more. Scintilla and its Qt bindings have been discussed. But 
I'm not very happy about it. I think most things we want to do are 
doable. Remembering we don't need to do everything exactly like in 
WinMerge 2.x.

Few days ago I got a new idea about using QtCreator's editor etc 
plugins. QtCreator is very nice development IDE and basically everything 
in it is a Qt plugin. Editor is code editor so it supports many features 
we want.

Which got me thinking about WinMerge 3 architecture. What if we did it 
similar way to QtCreator and heavily use Qt's plugin architecture... 
Perhaps not in level that everything is plugins but things like 
filtering, version control support, archive support etc. That is 
something I really need to think about more...

Following days I will continue working with very basic folder compare. I 
hope to get some very simple GUI done too. And start testing some new ideas.

Regards,
Kimmo

Re: [Winmerge-development] Does WinMerge do recursive directory comparisons using multiple threads?

[Kimmo V. <ki...@wi...>]

Hi.

> I have a 4 core HT system (8 effective cores).  When I do a large recursive
> directory comparison, it takes quite a while and doesn't seem to use all of
> my cores, which implies to me that perhaps it is not using multiple threads
> for the comparison.  Since files are independent of each other, it seems
> like it should at least spawn a thread for each file up to 1 to 2 times the
> number of effective cores, so in my case it would be comparing 8-16 files at
> a time and utilizing all of my cores.
>
> Does WinMerge use multiple threads in this manner?

No. WinMerge uses (only) two threads. First thread discovers items from 
the given folders to list. And second thread then compares items discovered.

Regards,
Kimmo

[Winmerge-development] Does WinMerge do recursive directory comparisons using multiple threads?

[Mark J. <mar...@gm...>]

Hi,

WinMerge is a great tool.  However, I have one issue that has been a problem
for me.

I have a 4 core HT system (8 effective cores).  When I do a large recursive
directory comparison, it takes quite a while and doesn't seem to use all of
my cores, which implies to me that perhaps it is not using multiple threads
for the comparison.  Since files are independent of each other, it seems
like it should at least spawn a thread for each file up to 1 to 2 times the
number of effective cores, so in my case it would be comparing 8-16 files at
a time and utilizing all of my cores.

Does WinMerge use multiple threads in this manner?

Thanks,
Mark

[Winmerge-development] Suggestion for install without admin rights

[<All...@ea...>]

 

My employer has developed a paranoia about admin rights, and this could
be true for many other large corporations. It would make life much
simpler if there was an alternate install that did not require admin
rights (possibly with some loss of features). Ideally, if it would cost
nothing in features, a change to the standard install that removed the
need for admin rights would require less support than maintaining two
installs.

To get around the "protections" imposed by help desk I've begun
installing whenever possible to a c:\bin directory. The various software
that work without admin rights using this alternate for the Windows
directory structure place all supporting files in a single tree under
the program's install directory. This may be inefficient since some
supporting files may be the same for multiple programs and save no space
through reuse, but it is straightforward.

	Allan Pfalzgraf 
	EATON

	4201 North 27 Street 
	Milwaukee, WI 53216 
	tel: 414 449-6872 
	fax: 414 449-6616 
	All...@ea... 
	www.Eaton.com <http://www.eaton.com/>  <http://www.eaton.com/> 

 

[Winmerge-development] Query about winmerge redistribution

[<Kau...@su...>]

Hi,

I am developing an application in .Net 4.0. This application should
support the comparison functionality and I was planning to use Winmerge
redistribution control (as a third party controls)in my application to
compare two files. Kindly let me know are there any redistribution
controls available which are compatible with .Net 4.0. And can I use it
for commercial use?

 

Regards,

Kaushal Shah

 

[Winmerge-development] WinMerge 3 Qt porting - new approach?

[Kimmo V. <ki...@wi...>]

Hi all,

as it seems Qt porting effort has been pretty much stalled already. For 
myself this is totally because of time constraints - this new WinMerge 
stable release effort (and all things around it) really don't make it 
any easier.

I found one interesting library provided by Qt developers (though it is 
pretty well hidden in their pages):

Qt/MFC Migration Framework:
http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/

I've looked at it and it offers some interesting possibilities to mix 
Win32/MFC and Qt code. And there is even example how to port MFC code to Qt:
http://doc.qt.nokia.com/solutions/4/qtwinmigrate/winmigrate-walkthrough.html

Basically using this fw we could start porting the MFC based WinMerge 
2.x part by part to Qt. Dialogs, controls etc. There are of course some 
limits what can be done and what not, but basically we can have pretty 
much working WinMerge all the time while converting code to Qt.

Of course Qt has very different ways to do things than MFC and just 
"porting" existing code is not good solution. This approach doesn't make 
WinMerge cross-platform or fix the underlying architectural problems. 
But it is a good stepping stone between pure MFC and pure Qt.

If I find time I'll setup new clone of WinMerge 2.x trunk sources to 
Bitbucket and start doing some experiments with that porting framework.

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] 2.14 stable branch created!

[Kimmo V. <ki...@wi...>]

Hi,

> The resulting differences are easy to find (thanks to WinMerge):
>
> * There are only a handful of affected doc sources with a few missing
> things (like, the xq option that you added in -r6941).

Ok, good that there aren't bigger changes missing.

> * The build files are broken.
>
> I think I could easily fix and test the doc problems manually if you
> like, because just a few files are involved. Let me know if you want
> me to do that, or if you prefer to fix the merge.

Yes, go ahead and fix the problems. As we haven't been doing any real 
merges in Subversion it is manual work anyway and you know the docs 
better than me.

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] 2.14 stable branch created!

[Denis B. <den...@gm...>]

Hi Kimmo,

Sounds like we at least want to bump the revision numbers in the
manual, so I took a look at the log of the Manual directory. At that
level at least, 2.14 doesn't seem to have all the 2.12 revisions. It's
missing from 6815 through 7033.

The resulting differences are easy to find (thanks to WinMerge):

* There are only a handful of affected doc sources with a few missing
things (like, the xq option that you added in -r6941).

* The build files are broken.

I think I could easily fix and test the doc problems manually if you
like, because just a few files are involved. Let me know if you want
me to do that, or if you prefer to fix the merge.

Regards,
Denis

On Wed, Sep 29, 2010 at 11:38 AM, Kimmo Varis <ki...@wi...> wrote:
> Hi,
>
>> Looks to me like the doc build scripts (Docs/Users/Manual/build/) are
>> out of date. At least, they're missing a lot of the changes that I
>> made for 12.2.
>
> That is weird. I created the 2.14 branch from tip of 2.12 branch so
> everything that was in 2.12 branch is in 2.14 branch now. For some reason
> your changes weren't in 2.12 branch at all?
>
>> Is this a mistake, or are the docs not going to be rebuilt for 12.4
>> and it doesn't matter?
>
> Sounds like a mistake to me. I don't think there will be any big changes for
> manual for 2.14. Or at least I'm not going to do any such changes.
>
> Regards,
> Kimmo
>

Re: [Winmerge-development] [Winmerge-dev] 2.14 stable branch created!

[Kimmo V. <ki...@wi...>]

Hi,

> Looks to me like the doc build scripts (Docs/Users/Manual/build/) are
> out of date. At least, they're missing a lot of the changes that I
> made for 12.2.

That is weird. I created the 2.14 branch from tip of 2.12 branch so 
everything that was in 2.12 branch is in 2.14 branch now. For some 
reason your changes weren't in 2.12 branch at all?

> Is this a mistake, or are the docs not going to be rebuilt for 12.4
> and it doesn't matter?

Sounds like a mistake to me. I don't think there will be any big changes 
for manual for 2.14. Or at least I'm not going to do any such changes.

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] 2.14 stable branch created!

[Denis B. <den...@gm...>]

Hi Kimmo,

Looks to me like the doc build scripts (Docs/Users/Manual/build/) are
out of date. At least, they're missing a lot of the changes that I
made for 12.2.

For example, in R2_14, build_common.xsl seems to have been branched
from -r 5784, which was commited August 10, 2008. The last version of
this file in 12.2 was -r 7703, commited November 10 2009.

Is this a mistake, or are the docs not going to be rebuilt for 12.4
and it doesn't matter?

Thanks,
Denis

On Wed, Sep 22, 2010 at 11:54 AM, Kimmo Varis <ki...@wi...> wrote:
> Hi all,
>
> as we are going to bump the version number of the next 2.12.x stable
> release to 2.14 I also created new stable branch for 2.14.x releases.
>
> The branch name is R2_14 and can be checked out from URL:
> https://winmerge.svn.sourceforge.net/svnroot/winmerge/branches/R2_14
>
> The branch was created from current 2.12 branch so all "stable" commits
> are already included.
>
> Now the 2.12 branch is finally and really closed, no commits there anymore!
>
> For 2.14 branch we are first in "soft freeze" mode meaning:
> - new features and UI changes can be merged from trunk if agreed so. So
> if you think some change would be good and is low-risk change you can
> propose it to be included. Use mailing lists of devel forum for that. Or
> submit a patch item to patch tracker. Don't bother suggesting big
> refactorings of code.
>
> - main focus should be to merge safe bug fixes from trunk to 2.14 branch.
>
> - After few weeks of this "soft" mode we go into normal "bug fixes" only
> mode and also freeze GUI strings for the release. When this happens
> depends how fast we merge things and how much there is to merge.
>
> So this is a nice opportunity to release really good (based on already
> stable version) WinMerge version if we are careful what we merge from trunk.
>
> And as before with stable branches, commit must be first done to trunk
> and only after that merged to 2.14 branch. Unless the commit is really
> 2.14-branch specific (rare commits are).
>
> Regards,
> Kimmo
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Winmerge-dev mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winmerge-dev
>

[Winmerge-development] 2.14 stable branch created!

[Kimmo V. <ki...@wi...>]

Hi all,

as we are going to bump the version number of the next 2.12.x stable 
release to 2.14 I also created new stable branch for 2.14.x releases.

The branch name is R2_14 and can be checked out from URL:
https://winmerge.svn.sourceforge.net/svnroot/winmerge/branches/R2_14

The branch was created from current 2.12 branch so all "stable" commits 
are already included.

Now the 2.12 branch is finally and really closed, no commits there anymore!

For 2.14 branch we are first in "soft freeze" mode meaning:
- new features and UI changes can be merged from trunk if agreed so. So 
if you think some change would be good and is low-risk change you can 
propose it to be included. Use mailing lists of devel forum for that. Or 
submit a patch item to patch tracker. Don't bother suggesting big 
refactorings of code.

- main focus should be to merge safe bug fixes from trunk to 2.14 branch.

- After few weeks of this "soft" mode we go into normal "bug fixes" only 
mode and also freeze GUI strings for the release. When this happens 
depends how fast we merge things and how much there is to merge.

So this is a nice opportunity to release really good (based on already 
stable version) WinMerge version if we are careful what we merge from trunk.

And as before with stable branches, commit must be first done to trunk 
and only after that merged to 2.14 branch. Unless the commit is really 
2.14-branch specific (rare commits are).

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] Bump stable fix version number to 2.14?

[T. G. <ti...@ge...>]

Hi!

> But then bumping to 2.14.x might confuse people following 2.13.x
> releases and thinking all the goodies in trunk will also be in 2.14.x.
> And of course we'd have to bump version number in trunk to 2.15.x.
> Which again would be a bit confusing.

For the normal users and download websites would be the 2.14.x version
number much better. They can see that the version number jump must meen
big changes like dropping Windows 9x support.

Ok, it will maybe confuse some power users, who play with the Trunk
versions but if we release a new 2.15.x Trunk version before the 2.14.x
release, they will use it and don't will care about version less 2.15.x!
:)

So I like the idea!

Greetings,
Tim


___________________________________
NOCC, http://nocc.sourceforge.net

Re: [Winmerge-development] [Winmerge-dev] Bump stable fix version number to 2.14?

[Christian L. <lis...@ho...>]

Kimmo,

I think the change to drop support for older Windows versions, on it's own, is enough to warrant that we bump the version to 2.14.0

Also, it's better to confuse the few people who follows experimental 2.13.x releases, than it is to confuse the vast majority of people who only downloads major stable releases.

Christian


From: Kimmo Varis 
Sent: Tuesday, September 21, 2010 9:58 AM
To: winmerge-dev ; win...@li... 
Subject: [Winmerge-dev] Bump stable fix version number to 2.14?


Hi all,

as I've mentioned before we must do new 2.12.x stable branch release to 
fix the widely announced vulnerability. And only way to do a "stable" 
release now is to do it from 2.12.x stable branch.

But we must do considerable amount of building changes etc also. So I'm 
wondering if we should actually bump the version number to 2.14.0 for 
the fixed release.

I'd like to do the version number bump because there is important (for 
some) changes like dropping support for old Windows versions and 
compiler/runtimes update. This kind of changes should not happen between 
stable releases. And I've mentioned we can take some more fixes from 
2.13.x branch to make it better update for users. So calling it 2.12.x 
is not really correct. It is more than 2.12.x.

Also bumping the version number allows us to merge some more changes, 
even some behavioral changes from trunk. Which would be very nice to get 
better WinMerge for users. It may be even though as starting new stable 
branch from 2.12.x branch. Where we'd really can release something 
stable for the users.

But then bumping to 2.14.x might confuse people following 2.13.x 
releases and thinking all the goodies in trunk will also be in 2.14.x. 
And of course we'd have to bump version number in trunk to 2.15.x. Which 
again would be a bit confusing.

Regards,
Kimmo


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Winmerge-dev mailing list
Win...@li...
https://lists.sourceforge.net/lists/listinfo/winmerge-dev

[Winmerge-development] Bump stable fix version number to 2.14?

[Kimmo V. <ki...@wi...>]

Hi all,

as I've mentioned before we must do new 2.12.x stable branch release to 
fix the widely announced vulnerability. And only way to do a "stable" 
release now is to do it from 2.12.x stable branch.

But we must do considerable amount of building changes etc also. So I'm 
wondering if we should actually bump the version number to 2.14.0 for 
the fixed release.

I'd like to do the version number bump because there is important (for 
some) changes like dropping support for old Windows versions and 
compiler/runtimes update. This kind of changes should not happen between 
stable releases. And I've mentioned we can take some more fixes from 
2.13.x branch to make it better update for users. So calling it 2.12.x 
is not really correct. It is more than 2.12.x.

Also bumping the version number allows us to merge some more changes, 
even some behavioral changes from trunk. Which would be very nice to get 
better WinMerge for users. It may be even though as starting new stable 
branch from 2.12.x branch. Where we'd really can release something 
stable for the users.

But then bumping to 2.14.x might confuse people following 2.13.x 
releases and thinking all the goodies in trunk will also be in 2.14.x. 
And of course we'd have to bump version number in trunk to 2.15.x. Which 
again would be a bit confusing.

Regards,
Kimmo

Re: [Winmerge-development] [Winmerge-dev] New 2.12.x stable release?

[Tim G. <ti...@ge...>]

Hi!

> I see we have two new translations in trunk, perhaps we can include them
> to the stable also.

I added the patch #3065119 <http://winmerge.org/patch/3065119> to the 
project page, which should backport Persian and Serbian languages to R2_12.

Greetings,
Tim

Re: [Winmerge-development] [Winmerge-dev] New 2.12.x stable release?

[Kimmo V. <ki...@wi...>]

Hi,

couple of clarifications are in place...

> The fact is as I've earlier told I don't have VS2003 anymore. So I must
> update the compiler and runtime environment also. Luckily we went
> through this already in 2.13.x so we hopefully can deal with it without
> too much pain. It doesn't make much sense to update to VS2005 runtimes
> so we will update to VS2008 runtimes. There is a risk in doing this and
> I really rather avoid it in stable releases. But we have no other options.

This unfortunately also means we'll drop support for Win9X/ME/NT4. But 
that is a compromise we have to make. Those OS versions aren't supported 
anymore by MS or many other vendors either. So nobody can blame us about 
that.


> Next 2.12.x stable won't be a similar stable update release than earlier
> updates have been. So I'm also bumping the version number to 2.12.10 or
> something like that.
>
> This is also a possibility to add some bug fixes to the release. There
> are lots of bug fixes done over last year and we can merge some of those
> also to 2.12.x now. I've no time to look through our changelog and check
> every commit but if you have fixes in mind you want to see in stable
> update please tell.

This still does not mean I'll take *any* fix or improvement. 
Translations MUST not change. And risk with the fix must be minimal. So 
only small-risk fixes for real user-visible problems.

I see we have two new translations in trunk, perhaps we can include them 
to the stable also.

It is also possible we do one "beta" release from 2.12 branch to test 
these things. We haven't been doing this before and the changes are 
anyway risky no matter what. So more public testing won't hurt. And 
better to have more testing in beta than break things for all users.

Regards,
Kimmo