Plan for WinMerge 2.16

[christianlist]

For the real development I'd move to Mercurial repository at Bitbucket anyway, like I suggested at developers-mailing list.

It may be a good idea to move to Mercurial.
It looks like it is more versatile than svn.

Would it be a good idea to look at the patches we have, and get the good ones committed before we move to Mercurial?
Or is it just as easy to apply those using Mercurial?

[kimmov]

For the real development I'd move to Mercurial repository at Bitbucket anyway, like I suggested at developers-mailing list.

It may be a good idea to move to Mercurial.
It looks like it is more versatile than svn.

Would it be a good idea to look at the patches we have, and get the good ones committed before we move to Mercurial?
Or is it just as easy to apply those using Mercurial?

I don't think there is a (big) difference in applying patches. If the patch is created with TortoiseSVN then it is easier to apply with the same tool.

I've described my method of doing the SVN to HG conversion at: https://bitbucket.org/kimmov/winmerge-v2/wiki/Home

[gerundt]

I created a Team account at Bitbucket and added us as admins:
https://bitbucket.org/winmerge

It use currently a mail address from me, but as Dean has admin-rights he could later change it to an adress from him. Or he can create mail address like bitbucket@winmerge.org which redirect to our addresses. In this case we have not only one person who can respond to mails from Bitbucket.

It think instead branches we will use own repos at Bitbucket, or? What will the name schema here? Should we keep the name "Trunk" for the unstable version? The website source could be move as "Website" to the Team account.

[kimmov]

I created a Team account at Bitbucket and added us as admins:
https://bitbucket.org/winmerge

Great!

It use currently a mail address from me, but as Dean has admin-rights he could later change it to an adress from him. Or he can create mail address like bitbucket@winmerge.org which redirect to our addresses. In this case we have not only one person who can respond to mails from Bitbucket.

Or it might be one mailing list? I'm not sure which kind of mails you get from team account? I guess notifications about new repositories etc?

It think instead branches we will use own repos at Bitbucket, or? What will the name schema here? Should we keep the name "Trunk" for the unstable version? The website source could be move as "Website" to the Team account.

I think it is best to start what we have now. So one repository for the code and another for the web site. Then we can later on separate repositories if needed/decided so.

I think HG's current branch support is so good you don't really need separate "branch" repositories for devel/stable/release branches. It is much easier to work with stable branches inside one repository, you can use bookmarks etc.

But I'd prefer separate repositories (created on demand) for different development work. Say developing new big feature, testing some things etc. The way HG makes branches permanent, we should not pollute repository with all the temporary devel branches.

And this is very much related to how we want to develop further. Do we have strictly controlled official repository or the same model we had with SVN each developer having write access. I'd actually prefer the stricter approach like Linux kernel etc projects have. So we have just couple of people (maintainers) having write access to the official repository. They review, accept and pull changes from the development repository to the official repository. Unlike with SVN, HG makes this kind of development easy and effortless.

[gerundt]

Or it might be one mailing list? I'm not sure which kind of mails you get from team account? I guess notifications about new repositories etc?

Since the team account seems to be a on own user, I think you can use the "Forgot your password?" function for it. So the mail address should be only private!

I'd actually prefer the stricter approach like Linux kernel etc projects have. So we have just couple of people (maintainers) having write access to the official repository. They review, accept and pull changes from the development repository to the official repository. Unlike with SVN, HG makes this kind of development easy and effortless.

Yes, this sound good!

[kimmov]

I finally updated my WinMerge-v2 repository at: https://bitbucket.org/kimmov/winmerge-v2

For some reason it misses the last commits from last 3 months from SVN. I have no idea why. But I have no time to look at that now. So it is not "almost" up to date.

[christianlist]

For some reason it misses the last commits from last 3 months from SVN. I have no idea why. But I have no time to look at that now. So it is not "almost" up to date.

It appears to be the exact same time when the sf.net upgrade happened.
At that time the url for svn changed, maybe it needs to be changed in bitbucket as well?

[kimmov]

Hmm. Bitbucket has nothing to do with my conversion. I use SVN repository backup to do the conversion. And the backup URL is documented at https://sourceforge.net/apps/trac/sourc ... on#Backups .

Now, if that URL has changed, then I miss the latest changes. Has it changed?

[After searching for sf.net support tickets...]
A-ha! The backup method has really changed and I was looking at old instructions. New instructions are at: https://sourceforge.net/p/forge/documen ... oject-scms

So I'll try my conversion again later today.

[jtuc]

In version 2.0 of xdoc2txt there is a C++ example which could easily be extended into a WinMerge plugin.
To distribute xdoc2txt with WinMerge, we would need to contact the author and get his permission.
We would also need to contact the author to see if he can provide a 64 bit version of xdoc2txt. Without a 64 bit version, it's pointless to even try this.
If anyone would like to take on this project or have a better idea, then please let me know?

WinMerge 2011's file transform scriptlets don't seem to have issues with 64-bit, nor any particular issue with calling 32-bit xdoc2txt.exe from 64-bit WinMergeU.exe.

Two remaining gaps to close for a fully functional 64-bit release are Merge7z and Frhed (heksedit). I plan to do the Merge7z part in near future, and hope that Kimmo will look after Frhed.

Restarting WinMerge 2 trunk is IMHO a waste of time.

[jtuc]

I also think we should simplify the 7-Zip support. Could we not deliver all componets with the normal setup and ignore a standaline installation from 7-Zip? It is really confusing and complex thing for normal users.

The problem is that we have no any control over 7-zip releases. The idea with separate setup was one can update just 7-zip support when new 7-zip version is released. We don't need to do new WinMerge release just for that. Waiting six months or one year for support for latest 7-zip is a bit long time.

Including 7-zip support in the installer itself may not be the best idea, but making it simpler to install would definitely be good.

I agree with Tim in this point. Coping with absence of Merge7z and related 7-zip files, as well as with the bunch of different 7-zip versions users may happen to have installed, causes way too much hassle for both users and ourselves.