ARIS - Q&A Session 9:00am CEST
ARIS - Q&A Session 6:00pm CEST

View all


I need support to knowledge how to use the versioning.

From some posts on the Aris Community i have understood that it is advisable to malke as few versions as possible: it is possible to create a versioning of a large number of models but it is forbidden to make many versions of single processes/models as the size of the Repository would grow exponentially.

Below are some data to show what was said above.

I merged from the Development Repository to the Production Repository 25 process (one process correspond at one functions trees containing CPE) for a total of 454 CPE.

At the end of the merge, 629 CPE are present in the Production Repository.

For each merge, before making the change ti Production, I performed the versioning of the version present in Production to historicize it; so in total I made 25 versions.

Once the operations were completed, the size of the Repository went from 24 MB to 109 MB.

Considering that the merged data correspond to a marginal part of the amount of data that will be present at full speed and that the number of versions will be at least 300 for year (update of function tree at least once a year), i wanted to understand if actually it is better to use the versioning, how to use it better, problems related to the excessive size of the Repository and any alternatives.

Thank you for availability,

Best Regards


by M. Zschuckelt
Posted on Sat, 10/12/2019 - 12:24


I am not sure, what the scope of your 25 versioning operations was. In ARIS the subject of versioning is always a model. So after you merged a model all you have to version is that specific model you merged.

Each versioning operation comprising one or more models does the following:

1. Create a snapshot of all the models in question (attributes of the model and layout of all occurrences of connections, symbols, attributes, graphical objects, OLE objects). Each model snapshot gets a new version number (counting from 1 upwards for each model).

2. Create a snapshot of all objects with their attributes that have occurrences in at least one of the models.

3. Create a change list recording all new model versions created in the versioning operation. The change list gets a change list number. It will also record all models as deleted that were part of any previous change list but are deleted in the workplace at the time of versioning. They will not show any more from this change list onwards.

When you look at the repository state recorded with any change list you will see

1. Every model version as recorded in the change list. All objects occurring in those models in the state they were in upon creation of the change list.

2. Every model version as recorded in any earlier change list in the state of the latest version up to the change list in question, unless it was deleted in any later change list (until the change list in question).

3. All objects in the state of the latest version (up to the change list in question) of a model they occur in.

So for your versioning strategy you should keep in mind to only version models where anything has changed. In your case it is sufficient to version the 25 models you merged. If the order of your merge is not important, you can also do just one versioning operation for all 25 models and they will all become part of a single change list.

As you can see the amount of memory does not increase exponentially. In the worst case, if you always version all models of the entire database and assuming your database is growing by one model with every versioning operation space would eventually grow quadratic. If you only version what is new I dare say your space consumption is near linear with the amount of new/changed content you version.

Consider that you should only version things that have a value worth conserving. So if you feel it is sufficient to consider all model approvals of a day together as the new state of the nation at the end of the day you could implement mechanisms to create only one change list each day. 300 change lists per year should not be anything you need to be afraid of. If you have 20000 per year you might question if there is any auditor interested in every detail of them. No matter which way you go you can record approvals in attributes of each model, so you are not dependent on a particular person initiating the versioning operation in order to have full accountability.

by Gianmario Boiocchi Author
Posted on Mon, 10/14/2019 - 12:14

In reply to by M. Zschuckelt


The reason for the versions is that the client where I work would like to make a version whenever the processes are published.

CPE are contained in a function tree.

From the tests I carried out, versioning the individual function trees (for a total of 450 CPE), the size of the repository has increased from 25MB to 110 MB.

I thank you for the answer, let's say you told me what I had more or less understood with the tests.

Maybe I'm wrong with versioning but I still have a big growth in the size of the Repository.

by M. Zschuckelt
Posted on Mon, 10/14/2019 - 12:52


good to see we have a common understanding on the inner workings of versioning and how to use it.

I would not be too worried. These were the first versions you created so all your CPE trees multiplied by 2 this time - the archived version plus the workspace state. Possibly your library objects multiplied by more than 2, since you did 25 versioning operations. I don't know if any of them changed between the versions.

I would expect that the scope of your individual versions will become a lot smaller after this first bulk version of 450 CPEs. Probably future versions will touch only a few CPEs at a time as updates for them are published. And as I said: Consider how often per day you want to publish. You could separate the approval from the publishing. Example: Upon approval you place an administrative lock on the model. Then at night you publish everything approved during the day and release the lock.


Featured achievement

You blog more than you breathe, and your articles stand out: Create 20 more articles, receive very good feedback and stimulate conversations
Recent Unlocks


Weekly | All-time
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon