Book a Demo

Author Topic: Handling several branches  (Read 6087 times)

Vinx

  • EA Novice
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
Handling several branches
« on: February 29, 2008, 08:44:20 pm »
Hi there,

the following issue came up in our team and we have not find a perfect solution for it yet:

We are developing several different branches of our software in parallel and we want to handle these branches in one model. That is, we want to have only one .ea file.

We are using the same classes in both branches, but the the classes (e.g. method signature, more or less methods) can differ from branch to branch. Though the common case is that they are almost the same.

And there are additional classes and packages in newer branches.

From time to time we merge the source files of older branches to the newer ones. Thus we have to do this in our model too.

Furthermore we want to create a documentation, but I think this will not be a problem if we have a proper model diveded into phases or branches or what ever.

I think this is a very common issue but I do not know what is the recommended solution for it.

I was thinking about transforming the model. What is your position on that idea?

Or have you got any other solutions for same or similar issues?

Thank you for any help or suggestions.

brannstrom

  • EA User
  • **
  • Posts: 35
  • Karma: +0/-0
    • View Profile
Re: Handling several branches
« Reply #1 on: March 11, 2008, 10:20:24 pm »
Hi!

We are also developing our model in parallel branches and will try to do it with EA.

We will do this by using a master and then create replicas for each branch. To have traceabllity a new baseline will be created in the master each time a new branch is replicated or synchronized.

I have not been able to test the function to show differences between baselines, because that function causes EA to crash. Even in a very simple model. I hope this will work in 7.1 since it is critical for us.

But I have written a plugin that helps the user to solve synchronization conflicts. The built in function to solve conflicts only gives you the objects guid and values that is different in the conflict. With my function it is possible to show the conflicting objects in its diagram. I think this will make it much easier to resolve conflicts.

brannstrom

  • EA User
  • **
  • Posts: 35
  • Karma: +0/-0
    • View Profile
Re: Handling several branches
« Reply #2 on: March 11, 2008, 10:43:11 pm »
Version 7.1 was released today. And now it works to show the differences between baselines!!!

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Handling several branches
« Reply #3 on: March 11, 2008, 11:15:57 pm »
Quote
Version 7.1 was released today. And now it works to show the differences between baselines!!!

Same problem here- we are constantly evolving a product but we also have to cope with addons which will have to be applied on older baselines.

A suggestion of mine which is untested yet: You can have different repositories for each branch (=baselines). Then you apply the changes on the baseline in question, open the main trunk repository and load the baseline from the branch repository.
EA lets you a compare and then merge it back by a simple click of the merge button (7.1 only).

As I said this is untested so any experience report is appreciated.

Oliver

brannstrom

  • EA User
  • **
  • Posts: 35
  • Karma: +0/-0
    • View Profile
Re: Handling several branches
« Reply #4 on: March 12, 2008, 06:25:09 pm »
Quote
A suggestion of mine which is untested yet: You can have different repositories for each branch (=baselines). Then you apply the changes on the baseline in question, open the main trunk repository and load the baseline from the branch repository.
EA lets you a compare and then merge it back by a simple click of the merge button (7.1 only).

I have been thinking of the same idea. But our model is version controlled and version controlled packages have version controlled child packages. And I found this in the documentation:

"Version controlled packages that themselves have version controlled child packages are not useful for Baseline comparisons, as Enterprise Architect expects a Baseline to contain all the information about child elements and child packages. Future versions of Enterprise Architect might relax this condition."


Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: Handling several branches
« Reply #5 on: March 12, 2008, 07:25:36 pm »
Quote
our model is version controlled and version controlled packages have version controlled child packages

How do you handle branching then? We are thinking of introducing a similar concept with EA and SVN, but it looks like tagging and branching will be tedious.

If we want to move a controlled package with controlled child packages to a branch, we can easily do it via SVN (or Tortoise) on the file system level. But then the top package in the new branch will point to child packages in the old branch (cause it only contains stubs for the controlled child packages), and the only "official" way to change this seems to be that we remove them all and import them again via GetPackage from the new branch.

When there are many child packages, and maybe even a deep hierarchy of controlled packages, this is painful and error prone. The automation API does not support GetPackage, so the only other way I can think of to do it would be to "cheat" EA by substituting all the UML:TaggedValue tag="xmlpath" values in all the XMI files (with an editor or with a self written tool using XSL).

Or am I missing something?

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Handling several branches
« Reply #6 on: March 12, 2008, 10:59:05 pm »
Frank et al,

Check EA 7.1. It has a Check In Branch feature that might ease this.

David
No, you can't have it!

brannstrom

  • EA User
  • **
  • Posts: 35
  • Karma: +0/-0
    • View Profile
Re: Handling several branches
« Reply #7 on: March 13, 2008, 02:26:14 am »
I have been testing this today:

Each branch is a EAP file. To create a new branch I copy the model I want to branch and rename it with a name containing the branch version(v2). I then open it and create a baseline named with the version of the branch(v2.0). When I want to merge the branch back to another branch(v1) I create a new baseline in this branch(v2.1).

I then open the other EAP file with the other branch (v1). Create a baseline (v1.4) to save the model before the merge. Then I open the "Manage baselines" and use the "Load Other Baselines" and open the v2 file. I select the baseline v2.1 and use "Show differences". Now I can select what I want to merge to the v1 file.

You can merge from "Show differences" even if the packages are version controlled and not checked out. But the result is not good, not everything is merged. I think you should checkout all packages before you try to merge. Then it seems to work well.

"Check In branch" is good when you whant to check in after the merge. But is no help when you want to check out all packages. I wrote a plugin that checks out a package and all its child packages.

/N

Oliver F.

  • EA User
  • **
  • Posts: 573
  • Karma: +2/-1
  • Aren´t we all in the model business ?
    • View Profile
    • Karl Storz homepage
Re: Handling several branches
« Reply #8 on: March 13, 2008, 09:26:59 pm »
Quote
I have been testing this today:

Each branch is a EAP file. To create a new branch I copy the model I want to branch and rename it with a name containing the branch version(v2). I then open it and create a baseline named with the version of the branch(v2.0). When I want to merge the branch back to another branch(v1) I create a new baseline in this branch(v2.1).

I then open the other EAP file with the other branch (v1). Create a baseline (v1.4) to save the model before the merge. Then I open the "Manage baselines" and use the "Load Other Baselines" and open the v2 file. I select the baseline v2.1 and use "Show differences". Now I can select what I want to merge to the v1 file.

This is exactly what I thought would work. Thanks for testing it.

Regards,

Oliver