The following screenshot is an illustration of the history browser. This particular screenshot is showing the version history of an MCSnapshot object (a Monticello package) for the PackageInfo package. The first pane shows a list of references to versions with the list culled to just the references beginning with "tags/v" (hence, only tag references are shown...if the list was not filtered, you would also see branch heads in this list). The second pane shows a graphical history of the versions with the newest versions at the top, oldest at the bottom, and edges linking ancestors with decendants. The red path is the path through history that is shown in the third pane (clicking on a path selects and deselects a path segment). The top node of the graph has a circle around it indicating the currently selected version (whose details are shown in the bottom, detail pane). The green nodes are green because they are selected (a right click would allow you to invoke a merge activity on those three versions). The third pane shows a brief description of each version (the timestamp of the commit, the author's initials, any tag or branch head info, and the first line of the commit comment. The bottom pane shows the details of the version (including the SHA-1 identity of the commit object, the class and SHA-1 identity of the committed object, the author, the committer, the timestamp of the commit, the name of any branches that pointed to the object at the time of the commit, links to parent commits, a list of references and the full commit comment.  The next screenshot shows the dialog that is presented when committing an object to a repository. First, you need to select the repository in which to commit the object. Then you need to identify the project within the repository. Then you need to name the branch (optional). Next is the author and committer. Then, finally, you have the commit comments. Note, much of this information is pre-filled for you when committing Monticello packages.  The final screenshot illustrates the N-way Smalltalk merge tool. It is capable of merging any number of Monticello source code packages. It works by loading a common base version into the image and then letting you resolve each of the conflicts between the versions as indicated by the browser. The top pane shows the versions being merged along with the base version that is a common parent to all of them. The context menu in this pane allows you to browse the packages, or browse various diffs of these packages. The next pane shows the progress of the merge activity. Each item in the list represents a conflict that needs to be resolved. Initially all items are red until some resolution is chosen. The boxes indicate how the given item was changed relative to the base for a given version (because we are merging three versions, there are three boxes on each line). A black box indicates that there was no change. A plus inside a box indicates an addition. A dash in a box indicates a removal. And, a splat in a box indicates a changed item. A green box indicates that a version that was chosen as the resolution to a conflict. Next, the row of source code panes shows the versions of the selected item from each of the three versions of the package being merged. These panes highlight the diffs from the base version in red. Some panes might have no changes (such as the third one shown). The numbered buttons below these source code panes allow you to show or hide each pane (giving you more room to see the source panes that might be important to the merge activity). The apply buttons allow you to select one of the versions and use it as the resolution to the conflict (causing one of the boxes and the bullet next to the selected conflict to turn greed). Alternatively, you may edit and accept the code in the bottom pane and the bullet for the selected conflict will turn green. Once you have resolved all conflicts, the working copy of the package in the image can be committed to the repository. In this example, the newly committed version will show all three of the merged versions as parents (thus preserving the full history of changes, including multi-way merges).  |
Trax >