Merging branches

pokorra

Hello Christian,
how is the work on the remoting branch progressing?
I am eagerly waiting for steps towards merging into trunk.

Could you please update your remoting branch by merging from trunk again?
I tried to do it, but got conflicts in Client AP code that I have no idea about anymore.

Thanks,
Timo

pokorra

I have created now a new branch on Launchpad, based on my plugin branch (which is based on your remoting branch).
Then I merged trunk into that new branch:
code.launchpad.net/_tpokorra/op ... uginbranch

I resolved the issues in AP GUI like this:

I compared your branch against trunk revision 2514, to see what the remoting changes have been in those files. It was only in function SearchFinishedCheckThread, TAsyncExecProgressState. For the AP files with the huge conflicts, I took over all the code from trunk, and then modified them in their SearchFinishedCheckThread function. This function was moved to new files, so I updated those.

See the commit message:
modified
csharp\ICT\Petra\Client\MFinance\Gui\AP\UC_OutstandingInvoices.ManualCode.cs
and csharp\ICT\Petra\Client\MFinance\Gui\AP\UC_Suppliers.ManualCode.cs regarding SearchFinishedCheckThread, TAsyncExecProgressState

reset csharp\ICT\Petra\Client\MFinance\Gui\AP\APMain.ManualCode.cs to the version from trunk. code to be modified has been moved to UC_OutstandingInvoices and UC_Suppliers.

csharp\ICT\Petra\Client\MFinance\Gui\AP\APSupplierTransactions.ManualCode.cs: took over code from trunk completely, and then modified the function SearchFinishedCheckThread similar to UC_OutstandingInvoices and UC_Suppliers

I hope this will help when you merge trunk into your remoting branch.
I am just compiling now.

all the best,
Timo

pokorra

Ah, another thing.
there was a file conflict on csharp/ICT/Petra/Server/lib/MCommon/FieldOfService.cs, which I did not handle correctly in my merge from trunk.
This file has been removed in trunk, so the conflict can be resolved by removing it in the branch as well.

Timo

pokorra

I am thinking again, what the general plan for OpenPetra is.
If there should be a Beta release within this current year 2014, I wonder if the merging of the http remoting branch into trunk should have a priority or not.
Matthias said last year (2013), that he planned that the team would work on the http remoting branch in February 2014.
Now this date is long gone, and I see the following things still missing:

standalone: should basically work, but there seems to be a couple of bugs and things to be looked into.
What is the priority of standalone for the OpenPetra team currently? It is nice to have a demo version for Windows, I guess. The advantage of the new standalone is that there is no client/server anymore, but really just one standalone .net application.
KeepAlive: I think this can be implemented in simple way. We should not need to worry what happens if just one screen crashes. We should only consider what happens if the overall connection to the server is lost.
We are using the remoting branch in the german office and it is working fine.
Clientside tasks: This should be implemented by Christian, as he wrote it for the .Net remoting as well.

Another advantage of the new http remoting is that my plugin system is based on it as well.
So from my perspective, I very much would like it to be merged into trunk rather sooner than later.

But if the stability of OpenPetra towards the Beta is more important to the project, I can live with that decision as well.
I just prefer some clear decisions rather than waiting forever for something.

Thanks,
Timo

christiankatict

Hi Timo,

Thanks for your work on that! Your solutions to the conflicts in your merge-from-trunk sound OK to me.

The plan was that I should wait until Alan is available to explain the changes and improvements that he did regarding logging of server activity and of page requests, as those would likely enable me to do better debugging (and Alan would have been available next week for that), but Alan and I got instructions in an email from Matthias last Friday, just before he left for a two week break:

'Alan and Christian: could you please hold back your work on the webservice branch for a while? I think we need to re-discuss how much effort is worth being spent on this big architectural change'.

So for the moment Alan and I won't spend time working on the webservices branch until we had a discussion on how to progress further, and when.

Kind regards,

ChristianK

pokorra

Hello Christian,
thank you for the reply.

Such a discussion certainly makes sense.

I have now simplified the procedure of getting the remoting patch applied to the recent trunk, in anticipation of the possibility that the remoting branch will not be merged into trunk in the foreseeable future.

Please see the repository github.com/SolidCharity/OpenPetraPatchRemoting
It has all the patches per file, that are necessary for the Remoting branch.
It also has a patch.sh script, that can be used to apply the patch to the most recent trunk, from lp:openpetraorg.
I have documented in the Readme.md, how to fix and update the patch for future versions of trunk.
That makes it much easier to deal with conflicts, because I will only have to deal with things that are related to the Remoting branch, and I can see what the relevant changes have to be.

I have done the same for the Plugin patch: github.com/SolidCharity/OpenPetraPatchPlugin
Obviously, that needs to be applied after the Remoting patch, because it depends on it.

As an example, I have created a branch from trunk, and applied both patches:
github.com/tpokorra/openpetragi ... ase2014_05

I will use this branch for the time being to create a release for the german office, and for Nazareth, and perhaps even for OpenPetra.now.

I am glad I can still work with trunk, even though the patches are quite big.

I hope that most of my work will be in Plugins anyway, in the next months.

I might propose a merge into trunk soon, removing the code that will then live in my plugins.

I hope this makes sense,
Timotheus