Eclipse Community Forums: EMF » Merging and VCS Best Practices

Home » Modeling » EMF » Merging and VCS Best Practices

Merging and VCS Best Practices [message #1063477]

Thu, 13 June 2013 05:30

Eclipse User

Hi,

most of you know that painful task of backporting features to an older
version of your software. When we do so we merge changes from the trunk
to the branch representing that older version using a VCS.

With one of my first projects, that used EMF, generated files without
modifications were not versioned, meaning that the one who checks out
and builds the software needs to generate the source code.

These days I also version the generated code so no code generation is
required when building the code and there is less danger to forget to
add a file to version control once I change "generated" to "generated NOT".

The .ecore, .ecorediag and .genmodel files are of course versioned as well.

When it comes to merging I do not care about the latter ones. In the
branches I only apply the merging operations to the generated code and
there I never generate code from the model. This sometimes means that I
have to touch generated code that I normally wouldn't, e.g. to fix
numerical constants in the EPackageImpl's representing my models.

Is there any best practice regarding the merging anc VCS business?

How do others cope with merging models or generated code?

Thanks and Regards,
Dirk

Re: Merging and VCS Best Practices [message #1063551 is a reply to message #1063477]

Thu, 13 June 2013 08:05

Eclipse User

Hi Dirk,

Quote:

Is there any best practice regarding the merging anc VCS business?

How do others cope with merging models or generated code?

Merging generated code is always tricky, and whether you modified it by hand may complicate the thing as you said.

I would say that the best practice is to merge the models, re-generate (with the same version of the generator as the one used for the code in the VCS) and then merge the generated code.

To merge the models, I recommend EMF Compare http://www.eclipse.org/emf/compare/ (it should be noted that I'm one of the committers of this project Smile

) The latest version is the 2.1 and it will be shipped with the yearly Eclipse release (Kepler) though you can install it in any version of Eclipse, starting from 3.5 and later.

[Updated on: Thu, 13 June 2013 08:06] by Moderator

Re: Merging and VCS Best Practices [message #1063592 is a reply to message #1063551]

Thu, 13 June 2013 09:14

Eclipse User

Hi Mikael,

thanks for the hint. I thing I have come accross it already. It kicks in
I believe when I do svn commit with subclipse and double check the changes.

Does it also perform automatic merging?

I'm not always happy with subclipse's merging capabilities so I often
work with TortoiseSVN. Do you know of a way to combine this with
EMF/compare?

I'm thinking about giving EGit a try but that's another story probably.

Regards,
Dirk

Am 13.06.2013 14:05, schrieb Mikael Barbero:
> Hi Dirk,
>
> Quote:
>> Is there any best practice regarding the merging anc VCS business?
>>
>> How do others cope with merging models or generated code?
>
>
> Merging generated code is always tricky, and whether you modified it by
> hand may complicate the thing as you said.
> I would say that the best practice is to merge the models, re-generate
> (with the same version of the generator as the one used for the code in
> the VCS) and then merge the generated code.
> To merge the models, I recommend EMF Compare
> http://www.eclipse.org/emf/compare/ (it should be noted that I'm one of
> the committers of this project :)) The latest version is the 2.1 and it
> will be shipped with this year's Eclipse release (Kepler) though you can
> install it in any version of Eclipse from 3.5 and later.

Re: Merging and VCS Best Practices [message #1063650 is a reply to message #1063477]

Thu, 13 June 2013 11:19

Eclipse User

Dirk,

Comments below.

On 13/06/2013 11:30 AM, Dirk Hoffmann wrote:
> Hi,
>
> most of you know that painful task of backporting features to an older
> version of your software. When we do so we merge changes from the
> trunk to the branch representing that older version using a VCS.
>
> With one of my first projects, that used EMF, generated files without
> modifications were not versioned, meaning that the one who checks out
> and builds the software needs to generate the source code.
I'm not a big fan of that approach. It's always good to know that your
code base is stable and if you get a new version of the generator tools,
it's good to know how it's generating code differently.
>
> These days I also version the generated code so no code generation is
> required when building the code and there is less danger to forget to
> add a file to version control once I change "generated" to "generated
> NOT".
Yes, that's the approach I generally use; I think most do.
>
> The .ecore, .ecorediag and .genmodel files are of course versioned as
> well.
>
> When it comes to merging I do not care about the latter ones. In the
> branches I only apply the merging operations to the generated code and
> there I never generate code from the model. This sometimes means that
> I have to touch generated code that I normally wouldn't, e.g. to fix
> numerical constants in the EPackageImpl's representing my models.
Fix? They shouldn't be broken!
>
> Is there any best practice regarding the merging anc VCS business?
>
> How do others cope with merging models or generated code?
>
> Thanks and Regards,
> Dirk

Re: Merging and VCS Best Practices [message #1063651 is a reply to message #1063592]

Thu, 13 June 2013 11:22

Eclipse User

Quote:

thanks for the hint. I thing I have come accross it already. It kicks in
I believe when I do svn commit with subclipse and double check the changes.

Yes. It's because EMF Compare is integrated with Eclipse Team and that Subclipse contribute to Team.

Quote:

Does it also perform automatic merging?

Not more automatic than the text comparison editor. You can accept all remote non conflicting differences at once if it's what you mean.

Quote:

I'm not always happy with subclipse's merging capabilities so I often
work with TortoiseSVN. Do you know of a way to combine this with
EMF/compare?

No idea how to do that Smile

We would have to create an RCP application able to take 2 or 3 files as input and define that application as the merge tool of TortoiseSVN? Not planned at all but we are ready to help you on that if you are motivated to implement it.

Quote:

I'm thinking about giving EGit a try but that's another story probably.

We are testing our Team integration mainly against EGit so I can tell it works pretty well with it Wink

Re: Merging and VCS Best Practices [message #1063801 is a reply to message #1063651]

Fri, 14 June 2013 05:44

Eclipse User

Hi Mikael,

the 1.2 version wasn't able to copy changes from one file to another so
I replaced it with the 2.1 RC4. But this version does not work at all.
The editor window just remains grey.

I am working with Eclipse 3.6. I just tried to copare two .ecore files
with Compare With->Each Other from the context menu.

Seems its not quite ready for productional use for everyone, but maybe
I'm doing things wrong.

How is it related to the EMF Diff/Merge project?

Regards,
Dirk

Am 13.06.2013 17:22, schrieb Mikael Barbero:
> Quote:
>> thanks for the hint. I thing I have come accross it already. It kicks
>> in I believe when I do svn commit with subclipse and double check the
>> changes.
>
>
> Yes. It's because EMF Compare is integrated with Eclipse Team and that
> Subclipse contribute to Team.
>
> Quote:
>> Does it also perform automatic merging?
>
>
> Not more automatic than the text comparison editor. You can accept all
> remote non conflicting differences at once if it's what you mean.
>
> Quote:
>> I'm not always happy with subclipse's merging capabilities so I often
>> work with TortoiseSVN. Do you know of a way to combine this with
>> EMF/compare?
>
>
> No idea how to do that :) We would have to create an RCP application
> able to take 2 or 3 files as input and define that application as the
> merge tool of TortoiseSVN? Not planned at all but we are ready to help
> you on that if you are motivated to implement it.
>
> Quote:
>> I'm thinking about giving EGit a try but that's another story probably.
>
>
> We are testing our Team integration mainly against EGit so I can tell it
> works pretty well with it ;)

Re: Merging and VCS Best Practices [message #1063853 is a reply to message #1063801]

Fri, 14 June 2013 09:57

Eclipse User

Hi Dirk,

Quote:

the 1.2 version wasn't able to copy changes from one file to another so
I replaced it with the 2.1 RC4. But this version does not work at all.
The editor window just remains grey.

I am working with Eclipse 3.6. I just tried to copare two .ecore files
with Compare With->Each Other from the context menu.

This is very strange because it is a very basic usage we tested a lot. Did you do the update from 1.2 to 2.1? I know that we have some issues with update and we are advising to first uninstall 1.x before installing 2.1. Could you have a look on this?

Quote:

How is it related to the EMF Diff/Merge project?

EMF Diff/Merge is a essentially a runtime technology to compare and merge EMF models. As such, it shares some common goals with EMF Compare. But, whereas EMF Compare provides full support for the Eclipse Team API (even the logical model one: see http://wiki.eclipse.org/EMF_Compare/Logical_Resources for more details) and then work with the VCS supported by Eclipse, EMF Diff/Merge does not integrate with Eclipse Team and then do not integrate with any VCS.

Previous Topic:	[EMF] EMF-generated model code can't be compiled if model contains class called "Container&
Next Topic:	[CDO] Security model

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:26:44 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter