Cornerstone 4.2 is now available! Dark mode, full macOS 10.15 support, in-app license key management, and more. Release notes.
Cornerstone includes documentation in Apple Help Book format. Alternatively, you can also browse the documentation online.
Cornerstone documentation
The official documentation provides a great introduction to Subversion for new users and system administrators alike.
Subversion documentation
Any additional questions, please check out our License Agreement section or feel free to contact us.
If you purchased an annual Cornerstone license on or after January 15, 2018, Cornerstone 4 is a free upgrade.
Customers who purchased a previous version of Cornerstone through the store on assembla.com can purchase licenses for Cornerstone 4. New license keys will be issued to you. The new license keys include all future versions of Cornerstone at no extra charge (with valid annual subscription).
If you purchased an annual Cornerstone license on or after January 15, 2018, Cornerstone 4 is a free upgrade.
Customers who purchased a previous version of Cornerstone through the store on assembla.com can purchase licenses for Cornerstone 4. New license keys will be issued to you. The new license keys include all future versions of Cornerstone at no extra charge (with valid annual subscription).
Yes, but you must purchase new licenses directly through Assembla. The Mac App Store provides no support for paid upgrades between versions of apps. Customers who purchased Cornerstone 3 can purchase updated licenses for the latest version of Cornerstone. New license keys will be issued to you. The new license keys include all future versions of Cornerstone at no extra charge (with valid annual subscription).
Cornerstone 4 supports App Sandbox. This means that it has restricted access to the file system. Without explicit permission from the user it is unable to read Cornerstone 2’s working copy registration database. Even if the user granted Cornerstone 4 permission to access the database, it still wouldn’t be able to access the working copies themselves.
Providing a migration solution is no simple task - working copies can be located in a number of locations and granting blanket access to some arbitrary directory in order to access all working copies contained therein violates the principles of sandboxing in the first place.
We decided that the best option was to let the user decide which individual working copies to import — which is simply a matter of dragging them to Cornerstone’s source list where they will be automagically grouped by repository.
Yes. We will continue to publish updates to Cornerstone through the software update mechanism built into the application.
As far as possible we will try to co-ordinate future releases of new versions such that they appear simultaneously on assembla.com and the Mac App Store.
You will need to remove the Cornerstone trial version from your Mac.
Place Cornerstone in the trash (and empty the trash) to re-enable the "Purchase" button in the Mac App Store.
The Mac App Store will show Cornerstone as "Installed" even if you purchased your license directly from assembla.com. However, you will only receive automatic updates to Cornerstone through the Mac App Store if you purchased through the Mac App Store.
If you already purchased Cornerstone from assembla.com and want to re-purchase the app through the Mac App Store then you will need to remove Cornerstone from your Mac. Place Cornerstone in the trash (and empty the trash) to re-enable the "Purchase" button in the Mac App Store.
No. Existing Cornerstone license holders must re-purchase the app through the Mac App Store.
No. Assembla is not offering refunds to customers who recently purchased Cornerstone directly from assembla.com.
The version of Cornerstone you purchased is functionally identical to the version of Cornerstone available through the Mac App Store. You can continue to enjoy the same functionality and future updates regardless of how you purchased the application.
No, we do not offer volume discounts to Mac App Store customers.
However, you will receive volume discounts on licenses purchased directly from assembla.com for 5 or more users. See the Cornerstone Store for more information on volume discounts.
Make sure that all the information you have entered into the window is exactly as it appears in the license mail you received. Check that you haven't included any unwanted text with the license key when copying it to the clipboard.
When entering license information into Cornerstone 1.x, enter the email address you used to make your purchase.
Enter the email address you used to purchase your Cornerstone license into the license recovery form and we will send you your license information.
You don't need to have Subversion installed to run Cornerstone because it comes with its own copy of Subversion baked into the application. This applies to all supported versions of macOS.
The best way for Cornerstone to ensures consistency across all versions of macOS is for the application to include its own version of Subversion.
This has the added benefit of allowing us to include the latest and greatest version of Subversion with our application without you having to worry about upgrading your macOS installation.
No. Cornerstone doesn't use the Subversion command-line tools and therefore doesn't contain them. Instead, Cornerstone uses the same libraries used by Subversion's tools, enabling the tightest possible integration.
Since OS X 10.8 Mountain Lion Apple no longer includes the Subversion command-line tools.
If you need to use the command-line tools then you will need to install them yourself, either by installing Xcode from the Mac App Store (and then installing the optional Xcode command-line tools) or through a package manager such as MacPorts.
If you installed a version of Cornerstone 3 downloaded from assembla.com then remove the folder at the following location:
~/Library/Containers/com.Assembla.cornerstone3
If you purchased Cornerstone 3 through the Mac App Store then remove the following folder:
~/Library/Containers/com.Assembla.cornerstone3.mas
Removing an app's container in this way can confuse the macOS preferences server. We therefore recommend rebooting your Mac after removing this folder before attempting to re-install Cornerstone.
Perform the following steps to remove all trace of Cornerstone 2 from your Mac:
Move the application to the Trash.
Move ~/Library/Preferences/com.Assembla.Cornerstone.plist to the Trash.
Move ~/Library/Preferences/ByHost/com.Assembla.Cornerstone.*.plist to the Trash (the exact name of the file is specific to your Mac).
Move ~/Library/Application Support/Cornerstone to the Trash.
Move ~/Library/Caches/Cornerstone to the Trash.
Note that Cornerstone does not store any repository or working copy data in these locations by default (i.e. not unless you explicitly direct it to). No user data (other than application configuration information) will be lost by removing these files.
URLs which contain a user name are specified in the following form:
scheme://user@server/path
Attempting to specify a user name which contains an @ character (i.e. in the form
user@domain) causes the host name to be incorrectly interpreted as domain@server.
RFC 1738 (a public specification which defines how URLs should be formed) stipulates that @ characters in user names
should be replaced with %40, e.g.
scheme://user%40domain@server/path
Note that Cornerstone v1.1 and newer automatically substitute @ characters with
the equivalent %40 encoding for user names entered in the Add Repository window.
Many thanks to Erik Aigner for the tip.
Cornerstone can't connect to the root directory of a pre-v1.2 Subversion repository. This is because
the server doesn't correctly report information about the repository. One workaround is to
specify a sub-directory with the repository URL (e.g. http://svn.server.com/repos/project/trunk
instead of http://svn.server.com/repos).
The likelihood that we can provide a solution to this issue in the future is slim as the issue lies in the interaction between the repository and version of the Subversion client as used by Cornerstone.
The only alternative is to ask your Subversion administrator (very nicely) if it would be possible to upgrade the repository to a newer, more current version.
Subversion ensures that changes made to a working copy are time-stamped to the minimum resolution of the file system. On macOS this defaults to one second. Copying or moving multiple files therefore takes approximately one second per file or folder.
Browsing a working copy in Cornerstone can become slow when:
A working copy is very large (i.e. contains many thousands of files).
Access to the working copy's originating repository is slow due to poor server performance or slow connection type.
Performance issues with large working-copies can be solved by:
Suppressing evaluation of external folders in working copy. This is done by choosing View > Hide Contents of Externals.
Reducing the size of the working copy. For example, if a project has a top-level directory (such
as trunk with numerous sub-directories containing modules, libraries or frameworks)
then you can try checking out the project into several working copies.
Connectivity-related performance problems can be solved by disabling the display of files' repository status until absolutely necessary. Do this by choosing View > Hide Repository Status.
The view changes described here will remain in effect even after the application is restarted.
When committing a directory (or an entire working copy) which contains a directory mapped to an external reference using the svn:externals property, changes in the external directory are not committed. To commit these changes, select either the external directory or the files with changes and commit them explicitly.
This behavior is inherited from Subversion and is by design: it prevents changes to external files or directories from being inadvertently committed when committing changes to the working copy that contains them.
If you encounter this error message when checking out a project even though the check out process
appeared to complete successfully, check that repositories referenced by svn:externals
can be reached and that the URLs are correct. This error is particularly likely if you are using
a local repository and then attempt to check out a project with external references to a public
repository on the Internet when you do not have Internet access.
Renaming a directory which contains an external reference causes Subversion to become
somewhat confused. On the one hand, it thinks the newly renamed directory is unversioned.
On the other hand, the existence of Subversion admin files (that pesky hidden .svn folder)
in the renamed directory causes no end of problems.
As a work-around, you can do the following to rename an external directory:
Create a new directory using the Finder or Terminal.
Add the directory to the working copy (done automatically if you create it with Cornerstone).
Edit the svn:externals property to point to the new directory.
Update the new directory. The directory will be populated with files from the external reference.
Moved any new or modified files from the previous directory to that which you created.
Delete the original directory.
The root cause is that macOS's HFS file system stores filenames containing accents in a manner which confuses Subversion. As a result, such files are displayed twice in working copies, once as unversioned and once as missing.
This is obviously a severe issue for those in non-English speaking countries who (quite logically) like to use all the letters in their alphabet in their filenames. Unfortunately, the issue lies out of Cornerstone's hands and squarely with the Subversion developers. They have acknowledged the issue (see Subversion issue #2464 if you want to get involved in the resolution process).
Here's some technical background for those who are interested:
File systems such as Windows' NTFS and macOS's HFS store the text for filenames using a character set called Unicode. Unicode can be represented (or encoded) in any number of ways. When it comes to accents, they can either be expressed as a single accented character (e.g. a German-language ä) or as two distinct characters, one of which describes the base character (in this case a) and the other the accent (umlaut). Both are perfectly legal forms, with the former known as Normal Form Composed (or NFC) and the later as Normal Form Decomposed (or NFD).
The difference between the Mac's HFS file system and others in the Windows and Linux worlds is that instead of accepting the accent form specified by an application when creating a file and then giving it back verbatim when reading from the file system at a later date, HFS converts all filenames to the decomposed form. As a result, the application encounters decomposed strings when it subsequently obtains filenames from the file system.
This presents a problem to Subversion which is comparing a working copy file list it obtained from the repository (in composed form) against filenames from HFS which are in decomposed form. High-level programming frameworks like Cocoa, Java and .NET handle these encoding differences automatically, but systems like Subversion which are written in low-level C need to be explicitly programmed to take such encoding differences into account. And this isn't currently the case with Subversion.
See the Note on Unicode Composition for Filenames from the Subversion developers for even more detailed background information and the complexities involved in implementing a solution.
The Subversion developers are aware of the situation but a solution isn't currently in sight as of late-2008.
If this matters to you then we suggest that you get in contact with the Subversion developers and voice your interest in getting this solved sooner rather than later. The majority of Subversion developers and users are probably English-speaking and use computers other than Macs so the issue may not be being addressed with suitable priority.
It can't hurt to raise the profile of the situation by letting them know that it affects you!
Our recommendation is to simply not use accented characters in your filenames. We realize this is draconian (we're located in German/French/Italian/Romansch-speaking Switzerland after all) but it's the only workable solution at the moment.
Subversion updates the revision of folders in the repository to reflect that of the newest contained file, but this updated revision number is only picked up by the working copy when updated.
This will cause Subversion to complain that the working copy's folder is out-of-date when attempting to commit folder modifications such as file addition/removal or property modification.
Update the working copy to bring the folder up-to-date with the repository and then retry the commit.
Plug-ins can interfere with the normal usage of Cornerstone and cause it to quit unexpectedly. If you are experiencing instability with Cornerstone then you should try uninstalling plug-ins to fix the problem.
What plug-ins? By plug-ins we mean haxies, application enhancers and system-wide extensions loaded via an input manager. Such plug-ins are loaded into every application running under macOS and attempt to modify the way the process functions in order to extend the application's functionality. Unfortunately such plug-ins can sometimes cause unintended conflicts which have an adverse affect on applications such as Cornerstone
Our experience has shown that often it is not enough to simply disable plug-ins (if the author provides such a configuration option). Instead they may need to be removed from the system entirely in order to avoid them being loaded into the Cornerstone process.
The native Mac file system, HFS Plus, supports two forks (independent data streams) called the data fork and the resource fork. Subversion can only handle the data fork, and if you attempt to commit a two-fork file, only the data fork will be recorded. Mac programmers using Subversion must consider how to handle this limitation.
The contents of the resource fork, if any, is structured data that programs read and write using the Resource Manager APIs. However, Resource Manager data is sometimes stored in the data fork. Therefore, while a nonempty resource fork is always a resource file, a resource file is not necessarily a resource fork.
We can roughly group files with resource forks into 3 types:
Files in which both forks are nonempty and important. These include applications and shared libraries in the old pre-Intel-Mac CFM format, and some older document formats.
Data files with a few inessential resources. Examples: an image file with a thumbnail icon as a resource, a text file with a resource recording a preferred font, or a document file with a resource recording a preferred application to open it.
Resource files with empty data forks. Typically these would be hidden inside an application package, or merged with other resource data by a development build system.
The first kind, true two-fork files, are the most problematic, but becoming fairly rare. If you wish to preserve such files in a Subversion repository, you will need to encode them somehow, perhaps in zip archives or using the applesingle or binhex commands.
In the case of expendable resources, you might choose to just forget about them.
A pure resource fork file can usually be converted to a data fork resource file without any loss of functionality. To find pure resource fork files in the current directory hierarchy, you can use this command:
find . -type f -exec [ -s "{}/..namedfork/rsrc" -a ! -s "{}" ] \; -print
You can convert pure resource fork files to data fork resource files with the following shell script.
#!/bin/sh
if [ $# -eq 0 ] ; then
echo "Usage: RsrcToData FILE [FILE ...]" >&2
echo "Example: RsrcToData *.rsrc *.ppob" >&2
exit 1
fi
while [ "$1" != "" ]
do
if [ -d "$1" ] ; then
echo "$1 is a directory" >&2
elif [ ! -e "$1" ] ; then
echo "$1 does not exist" >&2
elif [ ! -s "$1/..namedfork/rsrc" ] ; then
echo "$1 has an empty resource fork" >&2
elif [ -s "$1" ] ; then
echo "$1 has a nonempty data fork" >&2
else
# Here is the case of interest,
# empty data fork, nonempty resource fork
cat "$1/..namedfork/rsrc" > "$1"
cat /dev/null > "$1/..namedfork/rsrc"
fi
shift
done
exit 0
Alternatively, you could convert a pure resource fork file into a text file in the "rez" format using the DeRez command line tool. The rez file can be converted back to a resource file by Xcode as part of a build process.
The above text was taken from this excellent article on the Mercurial Wiki. It applies to working with Subversion and Mercurial alike.
Many thanks to Wolfgang Textor and Bastian Pfennigschmidt for bring this article to our attention.
To use Microsoft Word (2004 and later) as an external compare tool:
Using the AppleScript Editor app, create a script with the following contents:
on run argv set file1 to item 1 of argv set file2 to item 2 of argv tell application "Microsoft Word" activate open file1 set name1 to name of (info for file1) set doc1 to document name1 activate object doc1 compare active document path POSIX file file2 end tell end run
Save the file as MSWord.scpt.
Open Cornerstone's preferences by selecting Cornerstone > Preferences and activate the General pane.
From the External compare tool pop-up menu select Other Script... and locate the MSWord.scpt file.
Working copies can only be opened by the version of Subversion that originally checked them out. While newer versions of Subversion can upgrade the working copy to their version-specific format, attempting to open a working copy with an older version results in an error.
Care should therefore be taken to check out working copies in a version supported by all the Subversion client apps you use.
Cornerstone includes support for multiple versions of Subversion with the appropriate version being automatically selected when accessing a working copy. This ensures broad compatibility with the majority of other Subversion clients, but care must still be taken to ensure that the working copies are kept at a version supported by Cornerstone.
See the About window for a list of the versions of Subversion included with Cornerstone.
You can choose the format for a working copy in Cornerstone's Check Out window. Choose a version that is compatible with your other Subversion client apps. If you use Subversion in Terminal then use the version reported in Terminal.
You can find out what version of Subversion you have installed by typing the following command in Terminal:
svn --version
This will output something similar like:
svn, version 1.7.10 (r1485443) compiled Jan 15 2014, 11:22:16 Copyright (C) 2013 The Apache Software Foundation...
Note that this only applies to the Subversion command-line tool. Like Cornerstone, many Subversion client apps include their own version of Subversion. Consult the app's About window or contact the app's vendor for details if you suspect this to be the case.
The Serf HTTP library included with Subversion 1.8 contains a bug that causes HTTPS errors for repository URLs that include the username in the form:
https://username@server/repo
The technical background behind this bug is described in detail here, here and here.
Cornerstone contains an updated version of the Serf library that fixes this bug and therefore works as expected. However, other Subversion clients that have not been updated to use Serf 1.3.2 or newer will be unable to commit or update working copies checked out via HTTPS with Cornerstone.
How can you fix this?
If you only use Cornerstone to access your working copy then you can use 1.8 without issue.
If you need to access your working copies from another Subversion client then we recommend that you keep them in 1.7 format. There are few compelling reasons to use Subversion 1.8 and most users will be served just as well with 1.7, which is compatible with servers running all versions of Subversion.
If you built your own version of Subversion 1.8 then you can fix this bug by updating the version of Serf used by Subversion to 1.3.2 or newer.
Unfortunately none of the 1.8.x versions of Subversion to date mandate the use of a version of Serf that includes a fix, so we can't simply recommend that you update to a newer version of Subversion. Depending on how you built Subversion you will either need to rebuild Subversion entirely or just replace the Serf dylibs on your Mac.