The version control repository functionality described on this page is only available in the full licensed edition of the Use Case Editor. The 'Lite' edition that is available for free download and use only allows you to save models to XML files and reload them from these files. Version control is not integrated in the 'Lite' edition.

Before models can be placed under version control, a model repository has to be created, then the first version of the model needs to be checked into the repository. Thereafter, models are checked out, edited, collisions are resolved, then the models are checked back in.

Open the Use Case Editor in the usual way, and make sure you have loaded your currently stand-alone model that you want to put under version control.

To create a new repository, from the main menu of the Use Case Editor, select File | Version control | Create version store ... . This will bring up an information dialog, warning you that once you have created a version store for a model, the name of that model can no longer be changed. You should make sure you are comfortable with the name of your requirements model before you create the version store.

Click OK in the dialog to go ahead and create the version store. You will have to select the folder location where you want the version store to be placed.

The version control store for your current model is created. Note that the structure of the version control store is that it creates a new child folder in the selected folder location, whose name is the same as the model you have open, but without the .xml extension. The model repository is then placed in that folder with the name versions.xz. For example, if your selected folder is C:\SomeDirectory and the standalone model file you have open is called MyModel.xml, regardless of the folder in which the standalone model came from, the version control store will be at C:\SomeDirectory\MyModel\versions.xz. Each actual stored version of the model goes into this same folder as numbered compressed model files, 1.xz, 2.xz, 3.xz etc.

Note that initially the model is not checked in, so the version store is completely empty.

Once your repository has been created, it is simple to insert a model into the repository. Select File | Version control | Check in ... from the main menu. The ensuing dialog will warn you about checking for collisions with the latest checked in model to resolve collisions, but if this is the first insertion of the model this is not necessary.

In the text box on the check in dialog, provide some descriptive text explaining any significant changes to the model. Usually these would be changes that have taken place since the model was checked out of version control prior to editing, but for first check in will probably just identify any significant features of the model being checked in.

Click on Check in to insert this version into the version control repository. A dialog will appear telling you the version number of the inserted model, together with the date and time it was created.

To retrieve a model from the repository, select File | Version control | Open version store ... if the version store is not already selected. In the ensuing dialog, navigate to the folder that contains the version store. Recall that it has the same name as the model, but without the .xml extension.

The model store will open with a 'Browse version store' dialog, as shown in the picture below. Note that each version is listed, along with the person who checked it in, the date and time it was created, and the descriptive text that accompanied its check in. The entries are also listed with the most recent at the top of the list, as this is assumed to be the model you are most likely to check out to work on.

Select the version of the model you want to check out for editing, then click Check out ... to load it. 

A dialog will appear asking you to select a working folder in which to place the checked out working copy of the model's XML file. You can open and close the Use Case Editor and keep working on this local copy from the folder you select by using the File | Open...  and File | Save menu options until you are ready to do collision resolution and check the altered model back into the version control repository.

Before checking an edited model back into the version control repository, you will need to check your edits against any edits made by other authors in the latest model already checked in before your attempt to check in.

To do the model comparison between your local model and the model in the version control store, you should have already opened the version control store and have your local copy of the model open in the Use Case Editor.

Select File | Version control | DIfferences... from the main menu. This will compare every field in your model against the corresponding filed in the top checked in model of the version control system. Differences are highlighted in pink. Places where items are present in one of the two models but not in the other will be highlighted in pink on one side, and marked in gray a not being in the model alongside. An example of two models with a difference and a new item not present in the top version control model are shown below:

The left three columns of the difference view identify where in the model to look for the differing items. The rightmost two columns are the value held in your as yet unchecked in model, and its equivalent value in the latest checked in model of the repository. Your task is to make sure that what you finally check in is a model that resolves these differences to everyone's satisfaction.

Many check ins will only have one or two inconsistencies that have to be resolved. In this case most of the rows in the difference view are the same. You can select View | Differences only from the View differences window menu and it will restrict the list to just those entries that have inconsistencies.

Note that in its current form, this View differences tool does not let you edit the items from within the View differences window. It is intended in a later version of the tool that you could select the left or right values, or edit one of them to resolve the differences. As of today, you have to return to the model by closing the differences window, and make your edits there.