Re: [4diac-dev] Version Control for 4diac Projects (was: Reworking Deplo

[Alois Zoitl <alois.zoitl@xxxxxx>]

Hi,

voer the last days I spent some furhter time think ing on how the
multi-user situation could be improved. Here I noticed that not
dedicating one application per user but dedicating a subapp for each
user/submodule or component would be better. Here the mapping could be
rather fixed and each user would work on their subapplication. I think
here git could auto-merge rather easily. What do you think?

Also I think for 1.10 we should start and package EGit as part of
4diac-ide. Even if we are not haveing dedicated merge tools on the
graphical layouts it could help users managing their projects.

Cheers,
Alois

On Mon, 2018-04-30 at 12:34 +0200, Alois Zoitl wrote:
> Hi,
> 
> > > 
> > > I think this should be discussed in an own thread. But I really
> > > thought moving
> > > the 61499 XML file will improve the situation here as the changes
> > > the
> > > individuals may make could be seperated by applications or
> > > subapplications
> > > and therefore an auto-merge is possible. Hmhm. The longer I think
> > > I
> > > think
> > > the problem is mapping. There unorder changes may occure. A
> > > potential
> > > solution could be that we sort the mapping area by applications
> > > and
> > > subapplications. Then changes would occure in the same area and
> > > git
> > > merging should be easier. Do you know where most conflicts
> > > happend?
> > 
> > [Jose Cabral] I think the mapping will still be a problem... Maybe,
> > an application file for each application, with the corresponding
> > mappings in it, and another file with the devices (which won't
> > change
> > too much). The problem was mainly when someone change its
> > application, it was necessary to pull and make sure not merging
> > conflicts were present.
> 
> The problem with the current file structure of IEC 61499 is that the
> mapped FBs are also stored in the resources of the device. With that
> on
> every change in mapping also the device/resource content is
> changing. 
> 
> Therefore I really would be intereted what parts of the changes git
> was
> able to solve by itself and what parts resulted in conflicts. To see
> where changes should be added to improve the overall behavior. For
> example I noticed in Latex when useing Latex such that each sentence
> is
> placed on a separate line several people could work on different
> sections of the same file and git merged nearly always without
> conflict.
> 
> Cheers,
> Alois
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/4diac-dev