exported applications to .dat; can versions be renamed?

[Wayne Johnston]

I exported many config maps and applications from my repository to "manager.dat" for instance.

Then I decided I should rename the versions of some applications, and did that in my repository.

Is there a way to update the version names in the manager.dat?  Or remove them so I could export the new name?

[Marcus Wagner]

There are two ways to achieve that, a) and b) see below.

*** explanation: sorry, to avoid to misunderstand your question. To clarify: a manager.dat is (and was up to now) the only format of how VAST keep information outside of an image (an image in turn implies restrictions one having only one item loaded of potentially many editions).

The manager.dat holds the history (all editions) together with administration information, as well as the whole material from the product, e.g. versions, other editions, features, config maps which you did not load or you even cannot load (eg. code for other OS than your client).

In so far a manager.dat IS the repository. The content of a manager.dat is machine and OS independent.

A working image is always working in sync with exactly one manager.dat. A sync cannot create a new manager.dat (see export below).

This sync from an image can be 

direct (the manager.dat resides local to your development installation, using normal file access see above) or 

indirect (the manager.dat resides on any machine, not necessarily local, access from your image utilizes communication to a central service process who in turn uses direct normal file access to its manager.dat).

The point is:  file access to a manager.dat is always exclusive (only one process can access it at any time), no matter if done directly or indirectly.

That means collaboration (of a team running many images) usually requires that all these images indirectly access their common manager.dat over a shared central service process, who is in turn synchronising the accesses and having exclusive access to its manager.dat. 

This way even different development installations on different OS collaborate using the same single central service, which manipulates exactly one central manager.dat.

[Of course you can store many manager.dats centrally, but a service will operate only one of them on behalf of a client.]

Important is, all these manager.dats are equal in format and behavior, no matter where they reside and almost, how old they are. To the public, there are only two known versions, the old 1GB and the new 16GB format).

Only one process may access a manager.dat at any time.

An export of something out of a running image is the only way to create a new manager.dat.

So you wrote you first exported material from your repository (a central manager.dat) to a manager.dat you created new (that means, you copied things from one manager.dat to another, private one). 

Then you took corrective actions (version renaming etc.) in your image, that is in sync with what you called repository (see b) below why).

This obviously leaves your exported copy unchanged in the local, private manager.dat.

***end of explanation

To transfer changes to an already done export:

a) you throw away the earlier export and repeat the export to a new local manager.dat (that implies to export the changes done yet in the repository) or

b) you connect your image to this local manager.dat and repeat the corrective actions there again on this copy, however, leaving traces of its history. This connection is dangerous and complex, requiring your image to be in sync first with the (old) export.

I cannot recommend b) because I assume that this local manager.dat does not contain everything needed to run a development image, as normally one does not export this. Hence synchronising an image to a local manager.dat created by export and then to repeat the corrective actions there is likely to fail, besides of leaving tons of traces in it, as to answer to your last sentence: updating the export.

An export to a destination manager.dat is always additive, that is an export never changes something which was already exported, but can only extend it. Any changes made in an image are only transported to a manager.dat via a sync/connected image.

Going into detail: a version of an edition record holds a name written once (in the first export). Renaming it (by sync) from you image does not create a new record, so a new export of the same record to the same manager.dat will not end up in a changed name in the exported manager.dat.

This can be observed on all items, not only versions: users, user names, applications, configuration maps, methods, classes and so on.

If something lands in a manager.dat, it is there. I do not know any manager.dat reorganisation (instead of creating a fresh new one).

This quickly was painful in scratching quickly the 1GB (old version) limit and lead to the ancient relieve of the 16 GB new version manager.dat.

-

Marcus

[Wayne Johnston]

Thanks, I did "b".  Since the new manager.dat contains a small subset of the world, I received lots of errors about apps not found when switching to that repository, but that was fine.  I then did the renaming on the apps of interest.  

[Marcus Wagner]

A short conclusion: several administrative actions on the repository require the image to be connected and in sync with it. 

An exported manager.dat is not connected, as required (by these actions). 

So the order of work is: do any adminstration (connected) first before exporting s.th. 

If anything later turns out to be wrong/missing in the export (like change of names, versions etc.), correct that in the connected image and then repeat the export, that is, make a fresh one.

Most of the time it is too expensive to connect an image in sync to an export just to be able to administer it.

It is irrelevant whether this sync connection of the image to a manager.dat is established per file i/o or via a emsrv process.

-

Marcus