Best practices on branching?

[Geert Bellekens]

Hi,

I was wondering what would be the best practice in handling branching.
We have EA 7.0.815, a central (oracle) repository and a version control system (Serena Dimensions) integrated using the scc interface.
Imagine following situation:
We have released our application with version 1.0
We are now working on towards version 2.0
We get a major bug report that requires a patch on version 1.0 (so 1.1).
Now what is the best way to branch (a part of) the model to create this 1.1?
I tried getting the xml file (v 1.0) from the version control system, and importing that into a new root model (selecting "strip GUID's") to create an alternative copy, but that resulted in corrupting my whole project. (see post http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1187333928)

[thomaskilian]

Would be nice to have a cookbok for such a situation. Luckily I can still survive with checking in a complete model. But likely I'll face that situation where this won't work when we will use a common repository instead of individual EAP files quite soon.

[Martin Terreni]

Yep
I think it is very important that EA begins to fully support version control in this way. Many places must have different views over various versions to support multiple users.
Right now the only work around I can imagine is creating a new  project in version control and replacing its files with the old version.

[jeshaw2]

I think it is very important that EA begins to fully support version control in this way.

If they get into that, they will also need to provide a Configuration Management tool.  That could be a very sticky tool to develop because of the ramifications it has on the modeling process.

[Martin Terreni]

Not necesarily. When I used to work with ClearCase we cretaed "views" of the files for diferent branches and used them to load EA with defferent branches.
This is semething EA could do natively, insetad of us making a manual work arround.
I'm not sure CVS and TFS support this kind of functionality, but if they do then it would be a realy important thing.

[mattloft]

Martin,

We am currently evaluating EA. We use ClearCase Multisite UCM to manage numerous parallel development streams across teams that are globally distributed.

When you were using ClearCase, how did you go about merging different streams/branches?

Also, did you use EAP files or a central database repository?
It seems like EA splits up the current working model (EAP or database) with the XMI that is persisted into source control.
Does this mean to manage mutliple streams/branches you need to have an EAP or repository for each model?

Cheers,
Matt

[Martin Terreni]

We merged them through EA mainly, but also through CC merging capabilities.
We used diferent EAP files for different versions/teams.
It is same as with code, you keep XMI files for each version and create views over the different versions.
Then you can import them to a new EAP and you have your self a new branch for al the project = one EAP for each branch, some times we even held the EAP files in CC, but SAMBA\CC is a litle problematic with it sometimes.

I might not be helping much here, but is was a couple of years a go and this is what I remember.
If you have more spesific questions fill free to mail/PM me and I'll try to answer.

[mattloft]

Thanks Martin.

Does this mean that the EAP files are effectively disposable, as long you have the XMI files from version control?
In other words, does the XMI file hold everything that was stored in the EAP, without loss of data?

In that case each developer could:
1. Create a new, empty EAP file.
2. Import XMI package files from their branch in ClearCase
3. Make changes and check back into ClearCase
4. Discard the EAP

When it comes to merging branches/streams, you could either:
- Use EA to merge EAPs, then export back as XMI into ClearCase
- Use clearcase merging to merge the XMI files manually.

Matt

[Martin Terreni]

As far as we used EAP files are disposable if you don't mind loosing customed appearance of elements (and may be other graphical issues).
Both merges are OK. We used to choose CC merge just because it was faster I think.

You better play with it a little, EA was 4.5 when I worked with CC, it probably got some EA-CC issues solved since then...