Release Notes

Resolved Issues

As a result of user feedback we have changed the way that Cornerstone measures trial period usage.

v1.0 recorded the first run date and permitted unlimited use for 14 consecutive calendar days extending beyond that date.

Starting with v1.1, Cornerstone will allow the user unlimited access to the application’s features for 14 discrete days after the application is first run. Days when Cornerstone is not run are not counted against the 14 day trial period. This will give potential users far greater flexibility in deciding how and when they want to try the application.

Also, from v1.1 onwards, Cornerstone will remind the user that they are running a trial version on an daily basis.

Installing and running v1.1 will reset a previously-expired trial period, thus giving users who decided not to purchase a v1.0 license the chance to try Cornerstone v1.1.

Since its introduction, the single-user Cornerstone license has been priced at a discounted $59 introductory price (the 5- and 10-user packs were not discounted).

Prior to the introduction of v1.0, our intention had been to target a non-discounted price of $69 for the single-user license but to permanently reduce this to $59 with the introduction of v1.1 if the US Dollar/Swiss Franc exchange rate allowed.

Unfortunately, the recent turmoil in the financial markets and downturn in the US economy have resulted in the US Dollar maintaining its weak position against both the Swiss Franc and Euro. With the majority of our customers located in the United States we find ourselves unable to maintain the current $59 introductory price point.

The price of the single-user license has therefore been increased to $69 with the introduction of v1.1.

The pricing of the 5- and 10-user license pack remains the same at $259 and $449 respectively.

We have received literally thousands of mails from users in the four months since the release of Cornerstone v1.0 requesting new features and suggesting improvements.

We have listened very carefully to this input and worked hard to improve Cornerstone in a number of ways:

1. Performance

   We received a lot of feedback that Cornerstone’s working copy and repository browsers weren’t as snappy as they should have been in v1.0, so we made this our number one priority for this release.

2. Compatibility

   Subversion v1.5 was released too late for Cornerstone v1.0 so adding support to v1.1 became a top priority as user feedback made it clear that Subversion users are quickly transitioning to 1.5.

3. New Features

   Several commonly-requested features were added such as full documentation in Apple Help Book format, the ability to edit repository attributes and the display of hyperlinks for issue tracking numbers in the history browser.

4. Usability Improvements

   We have responded to user feedback by integrating over 25 improvements into v1.1 to improve usability and reduce the time it takes to perform routine tasks.

5. Bug Fixes

   In total, over 80 issues have been implemented/fixed, including numerous bug fixes and enhancement requests resulting directly from user feedback.

We feel that these improvements combine to make v1.1 a significant release. See the application’s release notes for a detailed summary of the changes made for v1.1.

v1.1 is a free upgrade for all v1.0 license holders and is available for immediate download.

New Features

1. Subversion 1.5 Support 

   Cornerstone 1.1 fully supports both Subversion 1.4 and 1.5. The versions integrated into Cornerstone are 1.4.6 and 1.5.3 respectively.

   Instead of providing a user preference for selecting between 1.4 and 1.5, Cornerstone enables the concurrent use of both versions, using 1.5 for all repository access and the appropriate version for each working copy encountered. This allows for maximum compatibility (1.4 working copies are not upgraded to 1.5 format automatically) while allowing the user to use 1.5 as necessary.

   The format used for new working copies is specified at check out time. The Check Out Working Copy window was extended with a format selection pop-up button (see Additional Options). The selection defaults to 1.4 for maximum compatibility.

   1.4 working copies can be upgraded to 1.5 using the new Upgrade Working Copy to v1.5… function on the View menu. A downgrade option from 1.5 to 1.4 is also available.

   Explicit support was added for sparse check outs. The Check Out Working Copy… function was extended to allow a) the format version (1.4 or 1.5) and b) the check out depth (1.4-compatible check outs only support All files and folders at all levels i.e. recursive, or Immediate files only i.e. non-recursive). The Update… function was also enhanced to support the new depth features of the underlying Subversion function. (#424)

2. New Add Repository Window 

   The separate New Repository and Open Repository windows were integrated into a single window which is accessible using the new Add Repository function. Integration of the two functions into one improves usability by making both functions accessible from the toolbar and source list action menu.

   In addition, the term Add Repository better reflects the nature of the function than the previous document-centric New Repository and Open Repository terminology.

   Finally, the introduction of new menu items for opening folders in Finder and Terminal resulted in an overloading of the term Open. Renaming the function to use the verb Add results in improved differentiation between the functions.

   For consistency, the previous Open Working Copy function was also renamed Add Working Copy.

   The new Add Repository window presents a tabbed interface with three sections: File Repository, HTTP Repository and SVN Repository. The separation of these domains allows for domain-specific user interface elements. For example, file browsing is provided for file repositories and tunnel selection is provided for SVN repositories. HTTP/SVN URL entry is now split across several files for server/host, port, relative path and credentials, thus reducing the likelihood of typos during URL selection.

   The new window also implements autofill, extracting URLs and file paths from the clipboard and pre-populating the window when opened. A Paste URL button is also available to paste a URL into the window while open.

3. Edit Repository Function Added 

   The action menu for repository source list items was extended with a new Edit Repository function which enables the user to change a repository’s URL or credentials. (#506, #528)

4. Custom Scripts May be Run After Commit 

   The log message window was extended to allow the user to select a script file for execution after completion of the commit enabling custom post-commit processing.

   The following script types are supported:

   • AppleScript
   • Automator Actions (Mac OS X 10.5 Leopard only)
   • Perl Scripts
   • Python Scripts
   • Unix Shell Scripts

   In all cases, the script receives a single argument: the root path of the working copy which contains the committed files.

   The selected script file is stored per working copy and is re-enabled by default for subsequent commits.

5. Support for External Compare/Diff Tools 

   1.1 adds support for the use of external compare/diff tools when comparing working copy files against BASE or HEAD, and when comparing revisions in the history browser. Explicit support is provided for the following applications:

   • Apple FileMerge
   • Araxis Merge
   • BareBones BBEdit
   • BaseBones TextWrangler
   • Macromates TextMate
   • Skorpiostech Changes
   • SourceGear DiffMerge

   The user selects the compare tool from the new External compare tool preference in the application’s General preference pane. The compare tool is then launched from th working copy browser using either File > Compare using Tool > Compare with Last Update (key equivalent: Cmd+Shift+B) or Compare with Latest in Repository (key equivalent: Cmd+Shift+H).

   Two revisions selected on a history timeline may also be compared using the external compare tool by selecting the new Compare using Tool > Compare Selected Revisions function from the File menu.

   Alternatively, the user may also select a custom UNIX shell script or AppleScript file, should integration be required with an application which is not supported out of the box. Custom scripts are required to take two parameters which describe the paths to the files being compared.

   When comparing BASE against the working version, BASE is treated as the original (or old) version and the working version as the modified (or new) version (the two file paths are specified in this order to custom scripts as well). As a result, most comparison tools will display the BASE version on the left and the working version on the right (BBEdit and TextWrangler behave somewhat differently, displaying the newer file on the left). The BASE file is locked before launching the external compare tool and should not be modified.

   When comparing the working version against HEAD, the working version is treated as the original (or old) version and HEAD as the modified (or new) version in a manner consistent with Cornerstone’s integrated comparison view. Once again, this is also the order in which the files are specified to custom scripts. As with BASE files, the HEAD file is locked and should not be modified. (#444)

6. Issue Tracking Numbers Displayed as Hyperlinks in Log Messages 

   Using the new Issue Tracking function (accessible using the repository source list action menu), a set of rules can be defined which control how issue numbers are identified in log messages and the URLs in the issue tracking system which they should link to.

   Each rule describes two things:

   1. The issue number pattern 

      The user can select from a set of pre-defined patterns using a simplified syntax (e.g. #number, [number] etc.) or specify a custom regular expression. Regular expressions should be specified using Perl-compatible syntax. Ruby extensions such as named groups are also supported. Detailed information on the supported regular expression syntax can be found on the Oniguruma site.

   2. The URL format 

      The URL format is used to generate URLs for issue numbers. {number} is used as a placeholder for the issue number matched using the pre-defined patterns. {0} is used to reference the entire matched text for custom regular expressions. {1} to {n} can be used to reference groups in the regular expression. Named groups are referenced using {name} where name is the name of the group.

   Matching issue numbers found in log messages are then displayed as hyperlinks, linking to the URL generated using the URL format associated with the pattern used to match the issue number.

   The user can define any number of rules. This enables use of the feature in environments where:

   • The format used for issue numbers has changed over time.
   • Issue numbers are formatted inconsistently by team members.
   • Multiple issue tracking systems are used, e.g. 1) an internal system for unit and integration testing and 2) and public support request ticketing system.

    

7. Quick Look Support Added to Working Copy Browser 

   Pressing the space bar (or Cmd+Y) now displays Quick Look for the selected files. The space bar is also used to dismiss the Quick Look panel.

   Quick Look is only available on Mac OS X 10.5 Leopard.

8. Syntax Coloring Grammars Added 

   Syntax coloring grammars were added for the following file formats:

   • Cascading Style Sheets (.css) (#10)
   • Adobe Flash ActionScript (.as) (#517)

 

9. Application Update Behavior can be Configured in Preferences 

   In 1.0, Cornerstone checked for updates once per day. There was no way to change this behavior.

   In 1.1, the application asks when run for the first time whether it should automatically check for updates when the application is started. Selecting No will suppress all subsequent background checks.

   In addition, a new option in the General preference pane allows the user to select from one of five behaviors:

   1. Manually
   2. When the application starts
   3. Every hour
   4. Every day
   5. Once per week

   Selecting Manually has the same effect as specifying No when prompted to check at start-up when the application runs for the first time, i.e. suppressing all subsequent background checks. The user still has the option of manually checking for updates using the Check for Updates… item on the Cornerstone menu. (#548)

    

10. Help Book 

    Cornerstone now includes full documentation in Apple’s Help Book format. (#131)

Performance Improvements

1. Working Copy Browser Performance Improved Significantly 

   The way in which Cornerstone reads status information for working copy items was changed to yield significant performance improvements. Additionally, the status is no longer re-read when browsing within the working copy. As a result, expand, collapse and filter operations are instantaneous, as is zooming into a folder (double-clicking in a folder) as well as switching between folders using the path bar.

   Working copy refresh logic was also optimized to only read repository status information (when enabled using the Show Repository Status option) for manual refreshes, updates, commits and lock/unlock operations. Refreshes after all other working copy operations (add, remove, copy, move, revert etc.) do not re-read status information from the repository. This makes working copy operations far more responsive when Show Repository Status is enabled. (#558)

   As a result of these performance improvements, the Mark Folders Containing Changes option in the View menu is no longer needed and was removed.

2. Repository Browser Performance Improved 

   The number of server requests made when switching to a repository for the first time has been cut in half, resulting in a 50% performance improvement.

   In addition, when adding a new repository, a server round-trip is no longer made to determine the repository’s root URL.

   Combining these two improvements, connecting to a new repository for the first time (using the Add Repository function) now takes 1/3rd of the time the comparable action would have taken in 1.0.

3. Show Repository Status is Now Disabled by Default 

   Displaying the repository status of working copy files is controlled using the View > Show Repository Status option. This was on by default in v1.0 but is now off by default in v1.1.

4. Browser Scrolling Performance Improved when View is Filtered 

   Browser view scrolling performance in 1.1 was significantly impacted by filtering. Scrolling performance in 1.1 is now identical in both filtered and unfiltered cases.

5. Diff View Layout Performance Improved Significantly 

   The time required to layout the diff view was cut by approximately 50%.

6. Diff View Rendering Performance Improved 

   Rendering performance in the diff view was optimized, making scrolling and text selection considerably faster.

7. Evaluation and Display of Externals can be Toggled for Working Copies 

   External directories can be very large (e.g. Boost C++ library) and their inclusion in status checks can have a significant impact on working copy performance. Cornerstone now includes the new view setting Show Contents of Externals which controls whether externals are included in status checks (this setting is disabled by default for new working copies). (#476).

8. Performance of Open in Terminal Function Improved 

   The Open in Terminal function was modified to execute significantly faster. In addition, a delay is no longer incurred when invoking the function for the first time.

Usability Improvements

1. Filter Display 

   In 1.0, all directories were always displayed. This behavior was changed for 1.1 where only ancestor folders of matching items are displayed. (#463)

2. All Filter Added 

   The filter (both status and text) can be reset using the new All filter button. (#539)

   The Remove Filter function on the View menu was renamed to Show All to be
   consistent with the button.

   Normally, the unfiltered expansion state is restored when switching from a filtered to unfiltered view. This can often result in the selection being lost. A new Show File in All function was added to the action menu for working copy and repository browsers to allow the selection to be maintained when switching to the All view.

3. Newer in Repository Filter is Only Available When Show Repository Status is Enabled 

   The Newer in Repository filter button is hidden when Show Repository Status is disabled. (#525)

4. Browser Selection Usability Improvements 

   In 1.0, Several selection-dependent functions (e.g. commit and update) allowed the user to ‘select’ the working copy’s top-level folder by clicking into the browser view’s background and clearing the selection.

   There were two problems with this solution: a) deselecting to select something isn’t exactly intuitive, and b) it only works when there’s free ‘background’ space to click into, and this isn’t possible when the browser has a large number of items displayed.

   1.1 improves the user interface in the following ways:

   • A working copy or repository’s root folder is selected by highlighting the item in the source list. The inspector tracks the source list selection when the source list is active (i.e. has the focus).
   • Selection-dependent functions are disabled when the browser is active but does not have a selection.
5. Alternate, Selection-Independent Functions Added 

   Some selection-dependent functions include a selection-independent alternative which works against the entire working copy or repository (i.e. the item’s root folder). For example, 1.0 provided both Commit Changes… and Commit All Changes… functions.

   1.1 extends on this concept by introducing the following new alternate functions which act against the working copy or repository root folder independent of the current browser selection:

   • Update… and Update All…
   • Update to Latest Revision and Update All to Latest Revision
   • Revert to Last Update and Revert All to Last Update
   • Resolve and Resolve All
   • Open Folder in Finder and Open Root Folder in Finder
   • Open Folder in Terminal and Open Root Folder in Terminal

   The alternate versions of these functions consistently use the Option key modifier combined with the key equivalent for the normal function. For example, Cmd+T is the key equivalent for the Commit Changes… function, whereas the Cmd+Option+T maps to Commit All Changes….

   These alternate functions are not displayed by default in the application’s menu. Instead they are displayed when the menu is open and the Option key modifier is pressed. Likewise, pressing the Option key while clicking the toolbar button will result in the alternate function being performed.

6. Inspector Displayed for Working Copies and Repositories in Source List 

   Selecting a working copy or repository in their respective source list causes the inspector to display information for that directory in the same manner as for items in the browser view. Likewise, the history view now tracks the selection of the source lists.

7. View Options Added to Working Copy Action Menu 

   ‘Show Ignored Files’, ‘Show Repository Changes’ and ‘Show Contents of Externals’ were added to the action menu for the working copy source list.

8. ‘Show Toolbar’ and ‘Customize Toolbar…’ Added to View Menu 

   Toolbar visibility and customization can now be controlled from the View menu.

9. Action Menu is Displayed for Right- and Control-Clicks in Source Lists 

   Right- and control-clicking in the working copy and repository source lists causes the action menu to be displayed for the selected item. (#435)

10. Filters Automatically Removed After Commit 

    If a view with a filter applied is empty after a user action then the filter is automatically removed. (#236)

    This behavior can be controlled using the new Show all when filtered browser is empty preference.

11. Text Selection Improvements in Text Diff View 

    The following mouse actions simplify text selection in the text diff view:

    • Double-click to select up to the nearest word boundary
    • Triple-click to select the entire line
    • Double-click the colored inner border of added/modified/deleted sections to select all text in the section
12. Source List Expansion and Selection is Restored at Start-Up 

    Cornerstone remembers the expansion status of items in the working copy and repository source lists and restores the selection next time the application is started (#488).

13. Expansion State of Folders in Browser Views Retained While Browsing 

    The expansion state of the folder tree in the repository and working copy browser views is maintain across zoom operations, i.e. browsing into a folder and then back out again (either using the forward/back buttons of the path bar/menu) will result in the previous folder expansion state being restored.

14. Inspector Sections can be Collapsed 

    Sections in the working copy and repository inspectors can be expanded and collapsed by clicking on the disclosure triangles next to the section headings. The expanded state of each section is restored when the application is restarted (#418).

15. Log Message Window can be Resized Vertically When Expanded 

    The log message window can be resized vertically when expanded to increase the number of changes visible in the change list. Both the collapsed and expanded sizes of the window are stored between sessions (#495).

16. Multiple Files Can be Opened Using Browser Action Menu 

    Multiple files can be open simultaneously using the Open command on the browser view’s action (i.e. context-) menu. Non-local (i.e. repository) files are downloaded in parallel (#503).

17. Default History Filter Changed to “Last 10 Revisions” 

    Changes made this week is not guaranteed to always result in revision matches, often necessitating a switch to an alternative filter in order to see the most recent revision for the selection. The default filter was therefore changed to Last 10 revisions (#497).

18. Ignore Works for Selections in Multiple Directories 

    The ignore/un-ignore function was limited to only ignoring or un-ignoring files in a single folder. Selection of files (or folders) in multiple folders caused the function to be disabled. This restriction has been lifted in 1.1. (#471).

19. Browser View Refresh Improvements 

    Working copies with “Show Repository Status” enabled are automatically refreshed when a change is made to related files in the repository. Likewise, committing or locking files in a working copy browser will cause the related repository view to be refreshed (#26).

20. Application Icon Bounces in Dock After Lengthy Operations 

    Application icon in the dock bounces once at the end of lengthy operations (such as commits, updates, imports, exports, log queries etc) if the application is inactive (#345).

21. Inspector Only Shows Property Fields Relevant to Selection 

    In 1.0, fields were shown for all svn properties (such as svn:ignore, svn:keywords) regardless of whether they could be assigned to the currently selected items. This behavior was changed in 1.1. The inspector now only displays the fields relevant to the selected items, with only svn:ignore being available for directories (#524).

22. Working Copies Can be Dragged to Other Applications 

    Items in the Working Copies source list can now be dragged to other applications such as TextMate, BBEdit and TextWrangler to open the working copy directory. Dragging the working copy to the Finder will result in the working copy being copied.

23. Error Alerts Extended to Include Subversion Error Info 

    Alert windows which are displayed as the result of a Subversion error can be expanded using the Additional Information disclosure button to reveal detailed technical information about the error. This may be useful in isolating the cause of the error (for example incorrect Apache server configuration). An action button in the alert window allows the user to copy the error details to the pasteboard. (#535)

24. View Option Buttons Added to Working Copy Status Bar 

    Option buttons for (from left to right) Show Ignored Items, Show Repository Status and Show Contents of Externals were added to the status bar at the bottom of the working copy browser. This improves usability by making the options’ states visible at all times (#525). Toggling options such as Show Repository Status is also more accessible as a result.

    The Show Ignored check button was removed from the filter bar as it had become redundant.

25. Browser Column Layout Restored at Start-Up 

    Changes to browser column ordering and width is stored per source list item and restored when the application is restarted. (#579)

Compatibility Improvements

1. SSH Support Improved Significantly 

   Previous limitations with SSH connectivity have been removed:

   • Cornerstone will prompt for the acceptance of server RSA key fingerprints. A new preference allows the user to specify that RSA key fingerprints should be accepted automatically for all servers.
   • The application will prompt for a password when password-only SSH authentication is being used. The user can store the password in the Mac OS X keychain.
   • Custom tunnels are now supported.
   • Passphrase-encrypted private key authentication is now supported (requires the use of an SSH agent on 10.4 Tiger).
   • Custom tunnels are listed in the protocol menu in Add Repository window.
2. Improved Working Copy Handling of Network Timeouts when Show Repository Status is Enabled 

   1.0 attempted to contact the repository using a simple socket connect before querying working copy status with the Show Repository Status flag specified in attempt to prevent long timeouts when the repository could not be contacted. However, this strategy caused a number of issues, especially when accessing servers via proxies. In addition, this strategy did not provide an adequate solution for tunneled protocols.

   1.1 improved the way in which the repository is contacted to better handle network timeouts. Cornerstone now displays working copy listings without repository status if a response is not received from the server within 1.5 seconds. The working copy browser is then refreshed to include the repository status information in successful completion of the request. Lengthy status requests therefore no longer interrupt working copy browsing.

   The Repository connect timeout preference was rendered obsolete by these changes and was consequently removed.

Behavioral Changes

1. Clean Function Always Cleans Entire Working Copy 

   The Clean function (View > Clean) was selection-dependent in 1.0. This behavior has been changed to always clean the entire working copy (#474).

2. Add to Working Copy is Now Non-Recursive by Default 

   The Add to Working Copy function always added folders and all children recursively in 1.0.

   This behavior was changed in 1.1. Folders are now added non-recursively by default (i.e. the folder is added but the folder’s child items are not added).

   This behavior can be changed using the Shift modifier key. Pressing the Shift key while the Working Copy menu is displayed reveals the alternate recursive function Add to Working Copy with Contents which has the key equivalent Cmd+Shift+D. (#196).

3. Keychain Items no Longer Shared with svn 

   In 1.0, Cornerstone used Subversion’s cached credentials wherever possible. Keychain items created by Cornerstone were also stored in a manner compatible with the svn command-line tools.

   While this increased interoperability it also resulted in confusion, with several users interpreting Cornerstone’s use of their cached credentials (and resultant failure to prompt for their password) as circumvention of their repository’s authentication policy. Furthermore, Subversion’s insistence on storing plain-text passwords in ~/.subversion/auth in certain circumstances is indefensible.

   As a result, 1.1 no longer shares credentials with Subversion, instead always saving the user’s credentials securely in the keychain. The items created by Cornerstone are clearly recognizable, being prefixed with the text Cornerstone. As a result, users upgrading to 1.1 will be prompted for their password when first accessing their repository. For repositories which allow anonymous read access, this may only occur when making a change to the repository for the first time.

   1.0 users upgrading to 1.1 who don’t use the svn command-line tools should consider removing all obsolete Subversion-created items from their keychain.

4. Modified Date Taken from File System for Modified Working Copy Items 

   In 1.0, the date displayed in the Date modified column of the working copy browser was equivalent to the date reported by Subversion as the Last Changed Date on the command-line (using the svn info command), i.e. the commit date of the item’s BASE revision.

    

   In 1.1, the date displayed for working copy items which have been modified (i.e. have a status of modified, replaced, conflicted, merged or obstructed) is taken from the file system and is consistent with that reported by the Finder. For all other files, the commit date of the item’s BASE revision is displayed.

   A new field was added to the working copy inspector to display the BASE revision date: the Committed field. The Date field was renamed to Modified in order to make the distinction between the two dates clearer. (#551)

5. Automatic Refresh Preference is Now Stored Per Working Copy and Repository 

   In 1.0, working copy refresh behavior was a global preference. In 1.1, automatic browser refresh is configured per working copy or repository using the new View > Refresh Automatically menu item.

   For working copies, this setting controls whether the working copy is scanned for changes when the application is reactivated. For repositories, it controls whether the repository is refreshed when changes are committed to the repository from a working copy.

Compatibility

Backwards Compatibility

1.1 is fully backwards compatible with 1.0. All configuration and settings (including license information) are transparently migrated to 1.1 when 1.1 is run for the first time.

Forwards Compatibility

The 1.1 configuration databases are forward-compatible with 1.0, i.e. you can run 1.0 and 1.1 against the same configuration databases in your Application Support/Cornerstone directory.

Your license information however is not forwards-compatible. 1.1 changes the location in which the license information is stored in order to prevent errors when synching preferences between Macs (license information is now stored per host). As a result, 1.1 migrates the old license information into a new location which is not forwards-compatible with 1.0.

For this reason, it is recommended that you backup your 1.0 preferences before running 1.1 for the first time. To do this, open ~/Library/Preferences and copy com.zennaware.Cornerstone.plist to a safe location.

To switch back to 1.0 from 1.1 perform the following steps:

1. Open ~/Library/Preferences/ByHost and remove the file com.zennaware.Cornerstone.*.plist (the exact name of the file is machine-specific).
2. Copy your backed up preferences file into ~/Library/Preferences.

Also, please note 1.0 will be unable to access any 1.5-format working copies or repositories created using 1.1.

Issues Resolved in 1.1 Beta 1

Issues Resolved in 1.1 Beta 2

Issues Resolved in 1.1 Release Candidate 1

Issues Resolved in 1.1 Release Candidate 2

Issues Resolved in 1.1 Final Release

Starting immediately, purchasing multiple licenses by adding a single item to the shopping cart with a quantity of more than one no longer results in multiple license keys being issued.

Instead, one license key will be issued for each shopping cart item purchased.

This change was made to simplify the management of license keys for users.

If you wish to receive multiple license keys for whatever reason then you can do so by adding multiple items to the shopping cart instead of adding a single item with the equivalent quantity.

Known Issues

1. SVN+SSH connectivity requires the use of a public/private key-pair. Use of password-only authentication is not supported in this version.
2. The RSA key fingerprint stored by the local SSH client must have been accepted before attempting to connect to the repository using Cornerstone. See Frequently Asked Questions for more detailed information.

Resolved Issues

Known Issues

1. SVN+SSH connectivity requires the use of a public/private key-pair. Use of password-only authentication is not supported in this version.
2. The RSA key fingerprint stored by the local SSH client must have been accepted before attempting to connect to the repository using Cornerstone. See Frequently Asked Questions for more detailed information.

Resolved Issues

Known Issues

1. SVN+SSH connectivity requires the use of a public/private key-pair. Use of password-only authentication is not supported in this version.
2. The RSA key fingerprint stored by the local SSH client must have been accepted before attempting to connect to the repository using Cornerstone. See Frequently Asked Questions for more detailed information.

Resolved Issues

Known Issues

1. SVN+SSH connectivity requires the use of a public/private key-pair. Use of password-only authentication is not supported in this version.
2. The RSA key fingerprint stored by the local SSH client must have been accepted before attempting to connect to the repository using Cornerstone. See Frequently Asked Questions for more detailed information.

Resolved Issues