Cornerstone 4.1 is now available! Shelve binaries, unregister license keys and more. Release notes.

Release Notes for 2.0.4

Filed under: Cornerstone,Release Notes — Administrator @ 6:44 am

2.0.4 is a maintenance release which solves issues uncovered since the release of 2.0.

2.0.4 is a recommended update for all users running 2.0.

Resolved Issues

# Description
Fixed a couple of minor memory leaks
1024 Cornerstone should keep track of the user’s last selected file repository compatibility setting
1026 The revision indicator in the repository browser’s status bar is not wide enough to accommodate 7-figure revision numbers
1037 Revisions displayed for cherry picking should be filtered based on the value in the “Merge from” field instead of displaying all revisions in the repository
1042 Cornerstone occasionally displays an alert with the text “An unexpected error occurred” after enabling annotations in the compare view
1043 Clicking “Merge Changes” in the merge view should cancel the running merge preview activity
1048 Cornerstone displays an error when the left/right/both selector is clicked in the compare view’s find bar
1055 Cherry picking merge UI should not start dry run for preview until one or more revisions has been specified by the user
1063 Compare view displays an error (“Cannot convert from ZSVNMineRevision to svn_opt_revision_t”) after resolving a conflict
1067 The diff3-cmd helper tool configured in .subversion/config should not be displayed while performing dry run merge previews
1071 The ‘Check out to’ field in the externals editor does not support folder names containing whitespace
1072 The document state for the externals editor window is not marked as modified when the property text is directly edited by the user

Designing an Icon in Record Time

Filed under: Cornerstone — Lawrence @ 6:25 am

Or: How we spent 2 weeks on a single icon for Cornerstone 2.

The icons used in Cornerstone 2 were never originally conceived as a complete set but came into existence gradually, pretty much at the same time as the feature set itself. The brief to design an icon for the newly added Branching functionality came somewhat late in the day when it had to fit into an existing icon set which comprised of the Merge, Update and Commit icons.

Packages that Branch

Branching Packages

The first step was to try and reuse the blue and red package metaphor for ‘changes’ as originally used in the Update and Commit icons and apply it to the context of branching. The result was 2 packages connected by a metallic ‘branch’ or conduit, with one package of changes extending away or branching off from the other. Not too bad for a first attempt.

Although icon design is not a ‘one design fits all sizes’ exercise we could not, even with extensive tinkering, optimize the icon for 32px. We tried various configurations of the 2 packages with the blue package placed above then below the red package and vice-versa. We also tried altering the shadows and highlights but still couldn’t get the level of definition we needed. The conduit had to be completely unambiguous for the metaphor to work and in the end we couldn’t help feeling that with this approach we were trying too hard to push the package concept where it just didn’t belong.

An Idea too Far?

Package colored leaves

Another way to main a consistent style apart from reusing metaphors and drawing technique is of course through color scheme. Moving away from reusing the package metaphor we decided on a more direct approach and came up with the idea of using leaves and their natural association with branching.

The color scheme translated well, especially with the edge highlights from the Update, Commit and Branch icons being used for the leaves’ veins. In fact we thought it looked so good that we were convinced it was more or less the final draft.

It was only after some time that it began to vex us. In fact several months passed as we continued development on Cornerstone 2 before realizing that the leaves were just not going to cut it. We decided that using them to represent branches which in turn represented branch functionality was one conceptual leap too far. Not only that but the leaves lacked the perspective shared by the Update, Commit and Merge icons.

Wood for the Trees

How about using Branches to represent Branches?

Now this sounds really crazy but we thought we’d give it a go. We’d use the color and perspective from the Update, Commit and Branch icons and apply it to the most familiar branching metaphor we could think of: the branching of the stem of a plant. Again the colors of the leaves’ veins would be based on the highlight colors used in the leaf icon but be bolder and drawn to indicate a fatter, rounder  more succulent leaf, much like an aloe vera plant.

Even after extensive retouching we couldn’t get the veins of the leaves to scale well and we wanted more than the shape of the leaf to indicate it’s purpose. By designing a more stylized leaf whereby the rib of the leaf is sharply recessed and blends seamlessly with the stem  (via the petiole for you biology buffs) we were able to achieve the level of definition at 32px that we were looking for.

As you can see this required some touching up and additional highlights but we were really pleased with the end result.

Try, Try again

Lessons Learned

Clearly icon design is not always, but can be, a highly iterative process. It took us nearly 2 weeks to decide on the final draft and while we’re really happy with the end result, we struggled at times to come up with a satisfying image that we thought users would easily understand.

When designing an icon that has to fit into an existing set it pays to remember that reusing a metaphor is not the only way to achieve consistency. Color scheme, perspective and drawing style, used in the right proportions (together with a good dollop of perseverance) can be just as important.