Version control status not checked with provider

[Martin Terreni]

We have a very big issue here with 7.5. EA is not checking the status through VC provider any more, it is relaying on the fact that all VC actions are done through EA, but let me show you one of our main scenarios which we have running now:
1)      SupertTelecom adapts new version of Amdocs products (Nextv)
2)      We create a copy of Nextv EA DB called SupertTelecom
3)      We copy the Nextv SVN repository content to anew repository called SupertTelecom
4)      We change all XMIs file configuration string
5)      We change the configuration string in t_genopt (because the same user may work both on SupertTelecom and Nextv) and in the package flags in t_package
6)      Now we have a copy of Nextvcalled SupertTelecom on which to design SupertTelecom customizations
The Problem:
      What if we skipped adding some XMI to VC? Or if we mixed by mistake packages from a wrong repository (which has happen to  us). In 7.1 we’ll notice immediately, sine we will see the red symbol next to the package and we can fix it, but in 7.5 a user will not see it and might check out the parent package losing all the data. This things may happen even if working through EA, since sometimes the problem  is in VC.

Is any one else finding this problematic? No ones cares?

[Frank Horn]

Haven't had the time to play with 7.5 yet (though I wish I had), but things like this could happen with 7.1 too. We have xmi files for SVN-controlled packages in folders also containing other sources (which are handled by TortoiseSVN). When I forget to check in from EA, but commit the top folder via Tortoise, the lock is being released on the xmi files, and next morning when I open EA the packages look like checked in. When I check out, my  data in the eap file are overwritten.

But it looks like the ways to destroy one's own work have multiplied. I guess they wanted to boost performance on start up and omitted the VC status check. In this case they should introduce a status check before check out and a suitable warning dialog.

Or even better: EA should do some baseline stuff in the background on check out and pop up a warning (with a big big cancel button) every time the data in the eap file are in danger of being discarded.

[Martin Terreni]

What's fritening me the most is that if you check out a package wich childern where in VC and their fails are missing then they will  just disappier, and you will have no working about it.

[Eve]

Have you contacted Sparx Support about this directly?

It sounds like you are doing something unusual with your repository and I'm not sure what the implications are.

[Martin Terreni]

I did, I'm actualy in contact with Ben about it, but it seemed to me important enough to post it.

[Frank Horn]

What's fritening me the most is that if you check out a package wich childern where in VC and their fails are missing then they will  just disappier, and you will have no working about it.

Not sure if I got this right. Do you mean when checking out a package with controlled subpackages, one of which is missing in the local working copy, EA 7.1 will show the missing package with a red dot, but EA 7.5 will simply discard it?

[Martin Terreni]

Exactly! this is the danger!

[Frank Horn]

Martin,

this is dangerous indeed and I think Sparx should revert to the previous (7.1) way in this respect. Obviously they have changed VC exception handling and sacrificed security for performance.

They will probably argue that there is no danger as long as we do all VC operations from within EA and don't fiddle with the local working copy behind its back. But fiddle we must, as long as EA does not support tagging and branching.

I can see, though, that Sparx would be hard taken to support it. VC systems have differing tagging and branching philosophies (e.g. SVN and CVS handle it in completely different ways) and Sparx would have to think up a common interface for all this and write individual implementations for the various VC systems. I'm not surprised by their shying away from this.

They might, however, with much less effort supply some utilities for those of us with a need for branching. The way it is, copying a project with EA xmi files to a branch in SVN can be done with these steps:

------------------------------

1. Select top folder in explorer and create branch via Tortoise (or command line) SVN.

2. Edit all xmi files in the new branch. If you had a separate VC configuration for the trunk (or old branch), change the

UML:TaggedValue tag="packageFlags" value="VCCFG=???

tags; otherwise, change the

UML:TaggedValue tag="xmlpath" value=???

tags.

3. Commit the changed xmi files via Tortoise (or command line) SVN.

4. Create a new EA project and import all top level controlled packages involved from the new branch via "Get Package".

--------------------------------

Step 2 could be varied by editing only the xmi files for the top level packages, and then doing the rest from within EA (kicking out all the nested packages and re-importing them from the new branch). But this is tedious. What I would like to have is a dialog in EA with a list (or tree) of all controlled packages and a possibility to edit their VC configuration without it taking immediate effect. And then a button to apply all the new settings, so that EA can do all the lengthy things (deleting packages from the model an re-importing them from the new paths) in one go while I'm having my lunch break.

I'm afraid this will remain a dream, but maybe one day they will at least include the VC operations in the automation interface, so we could write our own branching AddIn.

[Martin Terreni]

right now we do much of this work through DB and updating of files.