3.4.2 Comparing
snapshots
From the Changes tree pop-up menu, you can
Compare the
selected Version, Transaction or Graph with its predecessor. This will open a
text comparison of the selected state with its previous state.
Figure 3–52 shows the comparison of
some more changes to the Stopwatch Graph. Its Documentation property has been
updated (yellow), an Action object has been added (green), and the Mode Button
has been deleted (red). The text elements have Live Code hyperlinks, and
double-clicking a link will open that element in its current context in the
model. To the right of the scrollbar, a color map shows where to move the
scrollbar to in order to see the various changes: here, the yellow, green and
red areas are at the top, within the current scroll thumb area (and hence
visible in the text), with a couple more deletions in red further
down.
Figure 3–52. Comparing the Stopwatch graph to its previous version.
The
text lists the graph, its objects and bindings. Each element’s first line
shows its metatype (Graph, Object etc.), name, type and oid (object identifier,
unique within a repository). The first line is followed by an indented list of
its properties and their values (recursing into subobjects if present), and any
subgraphs. Reused elements are reported in full the first time they are
encountered, with only the first line on subsequent occasions. Similarly,
subgraphs are reported as only the first line. This approach is intended as a
good compromise between coverage and readability, and can be customized where
necessary – see ‘
Customizing
snapshot contents’ below.
When comparing a Transaction, the window will include all
graphs with changes, sorted by their name then type (if the graph name has
changed, the most recent name will be used). Each graph comparison will be
initially shown as just a header, similar to the single header for Stopwatch in
Figure 3–52. Clicking the
triangle will expand the header to show the comparison for that graph. You can
also press Space to close the current header and expand the next one.
When comparing a Version, the comparison is to the
previous Version, hence multiple graphs across multiple transactions. Rather
than show each graph many times, each time with just the changes made in a
single transaction, the changes will be combined and shown from the initial
state to the final state.
For comparing Versions when there have been multiple
users, only the changes by the owner of the selected Version will be shown.
Where necessary, the owner’s changes to the graph will then be split over
more than one textual comparison. For instance, imagine Anna has added objects 1
and 2, then Bill has added object 3, and Anna has added objects 4 and 5, with
each addition taking place in its own transaction. Anna’s Version will
then show her changes to the graph in two parts: the first comparison showing
the addition of 1 and 2, and the second comparison showing the addition of 4 and
5. Seeing just her own changes will allow her to document just the changes that
she made. Bill’s addition of 3 will be shown to him in his Version
comparison, and he can document it there. Each change is thus shown once, to the
user who made it, and can thus be documented once, without the confusion of
interleaved changes made by others being highlighted
too.
Customizing snapshot contents
The snapshot contents shown by Compare are produced by
running the _vcsGraphSnapshot()
generator on each graph in open projects. The snapshots are created at the start
of each transaction (or when opening extra projects later), and updated when you
open or Refresh the Changes & Versions Tool, or commit a transaction.
To customize the snapshot contents, you can change
_vcsGraphSnapshot() in Graph or by
overriding it in a particular Graph type. One rather common change has been made
particularly easy: if there are properties that you do not want to follow, you
can list them in
_nonRecursingPropertyTypes(): see
WatchFamily for an example. You could list properties that would take you out of
your current graph and into another, duplicating information already found in
that graph’s own snapshot. Or perhaps, as inWatchFamily, there is a
property that leads into a mass of objects that would produce a large amount of
text that you know will not change.
In an extreme case, you could even make the snapshot
completely empty. Since MetaEdit+ requires the
_vcsGraphSnapshot() generator to exist,
it is simplest to rename that to something like
_vcsGraphSnapshotOriginal() and create
a new, empty
_vcsGraphSnapshot().