Branching the Model for New R&D Team

[DMT]

Here's the deal. I have a new team that I'm ramping up that's going to add a new area to our product. We're going to branch the source code so they can work in isolation for about 6 months to build the new area, without interrupting the core product's team ability to ship additional releases during that time.

My challenge is determining how to allow the new team to work on their own independent EA model for the product, and merge their changes back into the "real" EA model (the one for the core team) when they are ready to merge their new area of the product into the main team's code base.

Until that time, I don't want the main team confused by changes and additions made by the R&D team so I want to keep them isolated.

Does anyone have advice on the best way to handle this?
* Make a copy of the model, export to XMI when ready to merge, and do a diff and merge, and import the result?
* Use version control at the package level? (I've played around with this and the implementation leaves a lot to be desired when you're used to Visual Studio's integration with Team Foundation Server.)
* Use version control of an entire EAP model file?

Any sggestions would be greatly appreciated.

Thanks,
Dave

[Geert Bellekens]

Dave,

The best way is NOT to branch, because merging is going to be a PITA either way.
I think whether or not you use version control is irrelevant, since you are going to work on different VC repositories anyway.
So basically what you'll need to to is create a separate model for R&D, and when the time has come to merge, you'll need to merge the xmi's from the branched model into the main model.
Those xmi's could be created by the VC integration, or you could create them manually, that doesn't really make a difference.
I've done a small merging operation a few months ago, and I would definitely count a couple of days to merge the whole thing.

So my advise, re-evaluate the need for branching the model. Are you sure there it is absolutely necesarry? In case you use code generation I could understand, otherwise you might be able to work something out without branching.

Geert

[DMT]

Thank you, Geert. It sounds like maybe we'll just try to "wing it," maybe using the baseline feature to help us understand what changed.

Dave

[Geert Bellekens]

Dave,

That's probably a wise decision.
You can use the baseline feature, or use xmi export to be able to compare later.
I would also advise to find some way to tag the changes made by the new team so you can find identify them.
We use some sort of xml like tags to structure the notes, but you could also use tagged values or something like that.

Geert

[DMT]

Thanks again for the advice! We just had a meeting and will be incorporating your ideas.

Dave