LoadControlledPackage: How does it work?

[bachlipp]

Hello,

I'm using SparxSystems EA 6.1.789 and have the following situation:

I've a shared eap file consisting of several packages, some of them are controlled by CVS. Now I want to checkout the latest version of all controlled packages, i.e. though there might be changes not checked in I want to restore the state recorded within the XMI files in CVS.

I want to do so via COM scripting.

My script basically works as follows:
I call "OpenFile2()".

Then I iterate through the Repository tree, and if some node turns out to be a package, I check whether it is controlled via access to its "IsVersionControlled" property. If it is, then on the project interface I call "LoadControlledPackage()" with the id of the current node in the tree, which is the result of accessing its property "PackageGUID".

After all controlled packages were loaded, I call "CloseFile()" and "Exit()".

When I inspect the resulting file, I don't find any differences, however. What is wrong with the above approach? The calls seem to succeed. I notice on calling "LoadControlledPackage()" that a small window pops up, but it gets closed again immediately after that, so I can't read any output there.

Any suggestions are appreciated.
Cheers,
Philipp.

[«Midnight»]

Hi Philipp,

I have not had time to run a test on this, but perhaps you are running afoul of a common problem for new EA programmers.

When you create or update any entity in EA the changes are not saved to the database unless and until you call the .Update() function on that entity.

This applies to elements, pacakages, connectors, etc. You get the idea. I'm getting the impression that you are targetting a package, essentially making changes to it via LoadControlledPackage() and then proceding without first calling .Update() on that package. My guess is that EA is moving on without saving your changes.

If this sounds correct based on your code, try calling .Update() after you do the load. Please let us know how this goes.

David

[bachlipp]

Hello David,

thank you very much for your quick response. Now I had time to add the update calls. However, I get an exception then:

Invoke of: Update
Description: Element locked

I played with the "Locked" property of the element associated to the package and with the "IsProtected" property of the package, but without success yet. Do I have to lock the parent packagem if I load one of its children again from source code control?

Cheers,
Philipp.

[«Midnight»]

It sounds like you might have to, but I honestly don't know.

Anybody have the answer to this?

In the meantime Philipp, try this on a model that has never been set up in CVS, to help determine if this is where the lock is coming from.

David

[bachlipp]

Hi David,

thanks again for your reply. Now I changed my code to add "update()" calls both to the Package after reloading it and to its associated Element. And I added "refresh()" calls to the parent Collection.

Still with no success. I can circumwind the locking problems by manually locking all Packages before, but though no exception caused by wrong locking permissions happens any more this way, the EA file doesn't reflect any changes caused by reloading a Package from source control.

I also tried to write the contents to an XMI file (using "ExportPackageXMI" on the Project interface). The resulting XMI file doesn't reflect the state stored in the source control repository, too. Writing XMI files furthermore requires huge resources (my EA file is 15MByte large, the resulting XMI file - that only contains a part of the whole model - will be 59MByte, and it takes about 45min and 175MByte RAM to produce it on my 3.2GHz Pentium 4.

Is it dangerous to use both the Repository interface and the Project interface at the same time? I do so, because the Package doesn't provide a "loadControlledPackage()" method. But I wonder whether the handle to the respective package is still valid after reloading the package.

So how to proceed? Maybe I'm on the wrong path - all I want to do is to automatically get an XMI file reflecting the exact state of a Package / Collection of Packages that is snapshotted in the controlled repository in terms of a series of files each representing a package, not the volatile state stored in the EA file.

Have a nice day,
Philipp.

[«Midnight»]

Hi Philipp,

Here's my thoughts on this, in no particular order.

It is not dangerous to use the Project and Repository interfaces together. You can get a reference to the Project interface from the Repository for just this reason.

It sounds like you are doing all the right things to update your packages and collections. However, these changes are not being checked into CVS. This could be because your add-in is not handling check-in, or becuase CVS does not think you have checked the packages out in the first place, or otherwise considers you to be some kind of read-only client. You'll have to investigate this further on your own I suspect, since this is probably very configuration dependant.

XMI tends to be quite verbose, but your situation sounds extreme. I've often worked with large XMI files but have not had the sort of delays you talk about. Getting stuff into and out of EA generally takes noticeable time, and often saturates the processor for a little while, but your experience certainly is worse than I've encountered. Have you tried tweaking the XMI version settings and related parameters? What about performing the exports to XMI manually; is there comparable overhead then?

Finally, have you tried your add-in on a copy of the EA file that is - and has not previously been - source controlled? I'd like to know if you can successfully retrieve the modified package contents in that case.

David

[bachlipp]

Hi David,

thanks for your quick response. I think there are two misunderstandings:

1. I don't want to programmatically check Packages into CVS. My collegues and I do that manually from time to time if our models mature. What I want to do programmatically is to check out the latest Packages stored in CVS and combine them to the overall model overwriting the changes I've not checked in yet. We've a shared EA file, and not all Packages are under CVS control.

2. Maybe I don't understand the "LoadControlledPackage()" method. I want to do the equivalent of "Package Control/Undo Checkout...", and my impression was, that the closes function was "LoadControlledPackage()". It was nice, if a future version of my automation furthermore could undo local changes and additionally restore the state of an arbitrarily tagged CVS version, not necessarily the latest one.

I have not yet tried your other suggestions.

Cheers,
Philipp.

[«Midnight»]

I think it would do us both some good to get Sparx to respond to your impression of LoadControlledPackage().

Please let me know what happens when you try the routine without CVS in the loop. I'll be off line for a while but will look back later in the day (Canadian time).

David

[bachlipp]

Hello David,

> I think it would do us both some good to get Sparx to
> respond to your impression of LoadControlledPackage().

The nice people told me that the the above command applies to packages under Package Control, i.e. those which are externalized into XMI files, but not to packages under Version Control.

Cheers,
Philipp.

[«Midnight»]

Which actually does make sense, since this functionality has been around - as has the API call - for quite a while. Although it may seem rather brute force, the controlled package idea can work wonders with a small team and limited back-end resources for source control. It can also be a godsend when people work at home, but sometimes have to share packages; source control locking can sometimes be a bit of a pain in this case.

Still, you'll have to come up with an alternative to solve your problem. At least you can put this approach to bed.