How to know when packages in VC have changed

[jamessher]

Hi,
I just set up an EA/Subversion environment and it appears to be working reasonably well except for this problem.

In order to test EA version control integration I have 2 projects in 2 different directories, each pointing at same project in subversion repo. This is to simulate 2 different users perhaps working on 2 different versions of the same project. I open one of the EA projects, check out a package, make changes, checkin. I then close the project and open the other one which should now have one of its packages out of date with version in VC repo.

How to know that the package in the newly reopened project needs to be updated from the VC repo ?

When I bring up the Package Control menu for the package which I know has changed in the VC repo there is no indication that I need to update from VC repo. The Get Latest and Get All Latest options are disabled.

Thanks
   James

[jamessher]

It would really be great to get an answer to this. Currently I am using TortoiseSVN to check if files in working copy are out of date with respect to the subversion repository but this is not very nice and I would have expected that it should be easy to tell from within EA if local model is missing new changes in the VC repo.
The equivalent operation in Eclipse for example is to 'sync with repo' and it gives a really nice indication of which packages/files in the working copy are older, newer, or to be added. It would be nice to be able to do this kind of thing easily in EA.

Thanks
  James

[Eve]

'Get Latest' and 'Get All Latest' are probably disabled because the model is shared.  (See Project | Version Control | Version Control Settings)

Set the model to private.

If you do this and select a 'Get All Latest' you should get the option of importing only the packages that have changed.

[jamessher]

Thanks Simon for the help. I changed the model to private and it works a lot better now.

However I have now hit another problem which I hope you can help me with. I am now trying to control nested packages. This appears to work OK but when I create a new project and do Package Control->Get Package to build up the project from VC only the top level packages are correctly imported. The nested packages appear in name only (they are empty) and I cannot import them from VC (they are missing from list when next do Package Control->Get Package).

In VC settings both 'This model is private...' and 'Save nested version...' are selected.

Ideally I would like to check out top level packages and then use 'Get All Latest' to populate the controlled nested packages. The documentation says this should work, eg.
"As a consequence of this new behaviour, if you check out or get a version controlled package with nested packages not already in your model, you will see stubs in the model for the nested packages only. If you do a "GetAllLatest" call from the version control menu, EA will populate these new stubs from the version control system.
Using the above technique it is now possible to populate a large and complex model from only the root packages, using GetAllLatest to recursively iterate through the attached and nested packages."

But when I do this the top level package is imported correctly but nested packages appear to remain as 'stubs'.

However I notice that if I import the nested packages first (starting with lowest in hierarchy) it works OK, but this is not really feasible since users would painstakingly need to get nested packages to build up the model.

Help greatly appreciated.

Thanks
   James

[Eve]

My guess, about what it happening is that the top level package was saved to version control before the subpackages were version controlled, and then not checked in again after they were.

Because of this, the package stubs that were imported don't actually know that they're version controlled.

So, try checking in the top level package again and then do the get latest in the other model.  If that doesn't work then I've probably hit the limit of my knowledge of this area.

[jamessher]

Hi Simon,

Unfortunately your suggestion did not work. There seems to be no way to populate the nested packages from version control.

This is now critical for my project so I will submit this problem via 'priority support request'.

Thanks
   James

[jamessher]

EA folks have had a look at this issue and it seems that EA stored the VC config UniqueID in the exported XMI files. In order for other users to correctly import the nested packages (Get Package for top level package and then use Get All Latest to have EA import all the nested packages) it is necessary for users to use the same UniqueID for their VC config !

This is an unfortunate restriction. Is it really necessary for the exported XMI files to contain the VC config UniqueID ? I would have thought that ideally the exported XMI files would not contain any user environment-specific details, thus making it easier to checkout/import into different users' environments.

Cheers
   James

[Paolo F Cantoni]

Agreed...

However, there may be some utility in providing it.  The bug is really that the value is used on import...

You could just as easily ignore it on input - which conceptually is almost the same as not providing it in the first place.  (If it ain't there, you can't import it...  )

Paolo

[jamessher]

Hi Paolo,

I'm not sure what you mean by "just as easily ignore it on input". There is no option to ignore it as far as I know. Apparently EA needs it to populate nested version controlled packages.

Following snippet from mail I got from EA support folks might be of interest...

"When the package data is exported, it includes the name of the VC configuration that is controlling it.   When you are dealing with nested, version controlled packages, the parent package also includes the filename and the VC config name associated with each of its controlled child packages.
If you have set up your second user's machine and used a different name (UniqueID) when defining the version control configuration, this could lead to the problem you are seeing.  The "Get Package" command will find the package files that are present in the working copy directory and hence you can import the top-level package, but when you invoke the "Get All Latest" command, the config associated with the "stub" does not exist on that PC, and so it can not be populated."

Regards
   James