Cornerstone 4.2 is now available! Dark mode, full macOS 10.15 support, in-app license key management, and more. Release notes.

Cornerstone 4 Release Notes

Filed under: Release Notes — Administrator @ 1:23 am

Cornerstone 4.0 is now available!

4.0 is a major release recommended for all users.

To upgrade to Cornerstone 4.0, you must have a valid annual subscription purchased through Assembla after January 15, 2018 at https://cornerstone.assembla.com/store. With a valid annual subscription, all future updates to Cornerstone can be downloaded for no additional charge.

4.0 runs on OS X 10.11 and later.

New Changes

  • Shelving – Allows users to temporarily “shelve” (set aside) in-process changes and revert back to the working tree – to quickly fix a bug on production, for example. Once done, users can simply retrieve their shelved changes and continue where they left off.
  • Checkpointing – Allows users to create a “snapshot” or copy of their repository at a specific point in time. If users experience a critical issue down the road, they can restore their project back to any checkpoint that they previously created. It’s essentially an undo button for major problems.
  • Subversion 1.10 – Cornerstone will now support all versions of Subversion above 1.7
  • Set Environment Variables With SSH Tunnels – A new SendEnv field allows users to set any environment variable using the form <variable>=<value>.
  • Integration with Assembla SVN+SSH – Cornerstone is now compatible with Assembla SVN repositories through SSH connections
  • Performance Improvements – Numerous code optimizations speed up overall application performance, especially when updating code from the central repository to Cornerstone

Shelving & Checkpointing Guide

Shelving and Checkpointing are new features introduced in Cornerstone 4.0. They let you save the effects of your work to a temporary storage and continue working on your working copy. Later, you can use that saved work by patching your working copy with the contents of your shelf or checkpoint.

Shelving and Checkpointing are similar features. The difference between them is what your working copy will look like after you make a shelf or a checkpoint. A checkpoint will save your modified working copy files into a shelf, but your changes will remain in the working copy. Shelving, on the other hand, will revert your changes, so your working copy will be missing all modified files (they will be saved in a checkpoint though).

Basic Usage

In order to be able to use Shelving and Checkpointing, you need to have a working copy checked out in Cornerstone. You can access the new features either using the Working Copy menu (Fig.1) or a right button menu on a working copy (Fig.2).


Figure 1: Working copy menu with Shelve and Unshelve


Figure 2: Left menu of Working copy – Shelve and Unshelve visible

Shelving and unshelving options can be used only on your local working copy, not on a remote repository. There is also a possibility to shelve a single file or a group of files. It is illustrated in a Figure 2.a.


Figure 2.a: Ability to shelve a file directly from a Working Copy Browser

If you select a file or files that are modified, added, or deleted, you can shelve them directly. They will appear as selected in Shelving window (Figures 2.b and 3). You cannot, however, select a directory or non-text file to shelve. So, the Shelve changes option will be grayed out on images or directories.


Figure 2.b: Items selected after a direct selection shelve

Shelving & Checkpointing


Figure 3: Shelve items

Figure 3 shows a window that is visible after the Shelve… command is clicked. In the top of a window we have a tab bar that lets us choose if we want to make a Shelf (Shelve and revert option), or a Checkpoint (Save a checkpoint (do not revert) ).

Below that we have an option to choose a shelf. We can either create a new one (default option) and enter a new name for it or choose an existing one. If you choose the existing shelf, SVN will add a new version to it, which will be visible in the Unshelve dialog, described later.

In this window we can optionally type a log message for a shelf. The log message is the same for every version within a shelf – it’s one log message for one shelf. However, it’s an optional selection and a shelf does not require a log message.

Finally, in the bottom of the window we are presented with a list of files that have been changed (in SVN terminology). We can select which files will be added to our newly created shelf/checkpoint. We do it by clicking them in the list. We can also use a button to select all.

After we complete all of the steps, the Shelve changes button will become active. When we press it, the shelf/checkpoint will be created.

Unshelve Window

Figure 4 presents the Unshelve window. It allows you to unshelve changes that were saved in a Shelve window. If you do not have any shelves or checkpoints, the options will be empty and you won’t be able to do anything here.


Figure 4: Unshelve window

If you have shelves or checkpoints, they will be visible in the first list. You can choose which one is to be unshelved. If you select a shelf, you will see all versions that were created for a selected shelf.

Note: the shelf can be empty, it doesn’t have to contain any versions. It can also create quite a few versions, depending on how you were using the shelving mechanism. Each version has a date modified field, which tells you when the changes were made.

The next step is to select a version that is to be unshelved. When you do that, you will see files that are stored within this version. This is a read-only field; you can only see a file’s name, nothing more.

Finally, there are 2 checkboxes. One allows you to delete the entire shelf when these changes are applied, and the second lets you delete the version that was applied and all newer versions, leaving the rest of the shelf untouched. It means that if you have versions 1,2,3,4,5 of your shelf and you are applying version number 3 and checkbox Delete selected and later versions after applying is checked, versions 3,4,5 will be deleted. You do not have to use any of these checkboxes, however you can only select one of them at the most (the other one will automatically get disabled).

There are, however, some special cases when Unshelving might not be possible. That is illustrated in the Figure 5.


Fig. 5: Unshelve window

Sometimes, the shelf that you’ve created might cause some troubles – it might not be possible to unshelve it without generating a conflict in a working copy. Currently, shelving in SVN 1.10 doesn’t support full merge, as SVN does. It cannot generate conflicted files. That kind of situation will be detected by the application. The files that will cause a conflict are marked with a red color. A message below the table appears. You can see the patch file (for the whole shelf) and correct things. When you click cancel and Unshelve again, if you properly handled the problems, you will be able to unshelve this time.

When all the steps are completed, the Apply shelved changes button is made visible. Pressing it will apply the shelved changes onto your working copy. You will see new files in Cornerstone view for a working copy.

Setting Environment Variables with Cornerstone

This feature allows users to set an environment variable when using SSH Tunnels (which should then be passed to the server as a SendEnv option)

Using the SVN Server Tab

When using the SVN Server tab, a new SendEnv field allows the user to set any environment variable they like (in the form <variable>=<value>). In this case, the value does not necessarily have to be REPO_NAME, and provides the user the flexibility to connect to repositories that support other variables.

Using Assembla with the Cloud Service Tab

Remember that to use SSH with Assembla, you must generate an SSh key and update your SSH config. Check out our existing documentation to see how. This implements the “export REPO_NAME=demo_test” portion of that documentation.

When using the Assembla Cloud Service tab, Cornerstone uses the values the user enters in the portfolio and repository fields and sets REPO_NAME=<portfolio>^<repository>.

Some Notes to Remember:

  • Selecting the SSH protocol from the Assembla Cloud Service tab will disable the username/password fields as they aren’t needed
  • If you check out a working copy from within the app, it should connect that working copy to the proper repository based on the REPO_NAME setting.
  • Pasting an Assembla URL (or having one in your clipboard when you open the window) will automatically take you to the Assembla Cloud service tab.