Using Embedded Wizard with software version tool

Question

Hello,

it is difficult when many developers work for one the same project. Without splitting the Units merging is nearly impossible. With Unit spliiting, the adding, removing, renaming of classes causes much effort in file handling.

It would be helpful if you could integrate the reordering mechanism from classes to units. The order of classes should always the same and new units added at the back. With reorder flags at the back of the unit files the order in the inspector could be defined.

Answer 1

Hello JK,

In Embedded Wizard the order of members is significant. It determines the order in which the members are initialized and the order of generated code fragments. It is thus inevitable to manage a valid list reflecting the order. In case of Split == true, the original order of unit members correlates directly to the order of entries within the .dir file.

Storing the order information locally (I suppose you mean within the ewui files containing the unit members) will not work since this approach is not reliable anymore as soon as files of different version are mixed. With this approach changing the order of one unit member would modify the order information of multiple files containing surrounding or following unit members. The task to merge the changes will become even more difficult. In worse case the original order information will become corrupted when different versions are mixed.

Probably, it would be better in your case to disable Split again? Then you have to merge the EWU files only - similar to how you merge C or C++ files when several developers are working on them simultaneously. In any case, the merging is inevitable. With Split=true we intent to reduce this work. A better solution, unfortunately, we have not found yet.

If you have many developers working on the same project, I would recommend to divide your project in many smaller units. Even units containing single components. The fewer units you are using, the higher the probability that two developers will modify the same unit. Then they need to merge the changes. Similar is true when coding C or C++ files.

Does it help you further?

Best regards

Paul Banach

Comments

Maybe you do not understand me correctly.

When using Split = false we get the very often conflicts, because the order of classes within a unit has changed. If you have three classes in one unit, for example NumPad, Keyboard and Menu. Those are stored in file in the order seen in the ew inspector. When someone changes the order most compare/merge tools can not handle that, because the ew classes are too similar and a mixture is the result. The problem is more critical the more commonalities there are.

My idea was that a list defines the order how classes are loaded. The order the classes are stored in file should not be effected. But this depends on how you are creating the ewu files. When saving, a new file must not generated, the existing one must be updated with the changes.

Is this a possiblity?

---

Hello JK,

in principle, setting the attribute Split to the value true disables already the problem with reordering. Only the index file .dir and the changes within the split files have to be merged. Compared to a C project, it is as if the developer team had divided few big C files in many small C files, each containing a separate C function. The probability of two developers modifying one and the same function (and thus file) is reduced significantly in this case. Hereby most of the changes can be merged automatically.

From your question I have understood, that using Split=true is not your favorite. The alternative would be to have all unit members stored within one large EWU file (Split=false). We have discussed your suggestion and from technical point of view it would be possible to modify Embedded Wizard so that:

1. The order of members within the unit file (EWU) is not changed when the user reorders the members in Studio.

2. New added members are arranged consequently behind the originally loaded project members within the EWU file.

3. The expected order of members is listed explicitly at the end of the EWU file. A kind of index. Please note, that merging this index can't be eliminated. Incorrectly merged index will affect the order of members how Embedded Wizard processes them.

Are you sure it will make the merge task easier for you? Or are there other aspects I have not understood from your question?  Does it happen that often in your project that the developers change the order of unit members?

Best regards

Paul Banach

---

Hello Paul,

in the early development stage, classes are othen renamed. In a more advanced state splitting won't be such a problem. 

Does it happen that often in your project that the developers change the order of unit members?

Not such often, but when this happens, it takes very much time to solve the conflicts. This is not viable for us.

Are you sure it will make the merge task easier for you? 

The way i imagine it, it would be helptful, because you do not have hundreds of files in contrast to splitting. And it should not be a problem, if classes are reordered. In fact, I can not evaluate when I have tested it with a realistic scenario.

I will discuss this with the team. Maybe splitting is currently not such a big problem anymore. Then I will give you some feedback. 

How much effort does the change of the mechanism involve?

Kind regards 

Jonas

 

 

 

 

 

---

Hello Jonas,

thank you for the further details. I have created a new entry in our issue tracking tool describing this modification. As next we will discuss internally how to proceed in this case. The expected effort should be manageable, I suppose.

Best regards

Paul Banach