What’s New in AccuRev 7.3

Highlights of new developments in AccuRev 7.3 are captured here. The following sections describe the new PulseUno Code Review feature, several enhancements to the AccuRev GUI, and some new Unix tools for backup and restore.

PulseUno Code Review

AccuRev 7.3 provides an exciting new way to do code reviews. AccuRev is now integrated with PulseUno, a web-based application, and together, they enable users to easily perform code reviews on AccuWork issues (change packages). This section gives an overview of how PulseUno Code Reviews work.

Code Review can be enabled on a per-depot basis. Before users can work with PulseUno Code Reviews, the site administrator must configure AccuRev with PulseUno. For instructions, see Configure AccuRev with PulseUno Code Review .

Additional information about using PulseUno Code Review is available in PulseUno Code Review FAQ .

Creating Code Reviews in the GUI

Code Reviews can be created from several different places in the AccuRev GUI:

In AccuWork’s issue form (toolbar):
In the Stream Browser’s Active Issues default group (toolbar and context menu):
In the Show Active Issues view (toolbar and context menu):

Code Review States

A PulseUno Code Review can be in one of several states. Those states and the transitions between them are shown here:

The states are:

Draft: The review is being modified by the user who is the author.

In Review: The review has been published. Reviewers can add comments and vote on the review.

Approved: The review’s changes have been accepted.

Rework: The review has been sent back to its author with suggestions for improvement.

Completed: If there are no problems, the Approved review is normally marked as Completed by the author.

Abandoned: A review can be changed to Abandoned at any time by an administrator. The review is closed and removed from circulation.

Updating Existing Code Reviews

Each AccuWork issue (change package) can have only one PulseUno Code Review. The code review initially contains the change package’s transactions as of the time the code review was created. (Change package transactions can be viewed in the issue’s Change Package History in AccuWork). As additional transactions (e.g., Promote, Send to Issue) involving the change package occur, users can update the code review in PulseUno:

If a code review is in Draft state (unpublished), it can be updated any number of times.

If a code review is In Review or Approved, it must first be sent for Rework before it can be updated.

If a code review is Completed or Abandoned, it can never be updated. Changes should be moved to a new issue to be reviewed.

In AccuWork, the Start Code Review button/menu item changes to Update Code Review for issues that already have a code review associated with them.

Access PulseUno

There are several ways you can access PulseUno to view and edit code reviews:

Open http://myserver:8080/pulse:8080/pulse in a browser.
Select Open PulseUno in the AccuRev GUI’s top-level View menu:
When viewing an AccuWork issue that has an associated code review, click the PulseUno button next to the Code Review field to open the default browser directly on that code review:

Use your AccuRev credentials to log in to PulseUno.

Example: User Logan Creates His First PulseUno Code Review

Logan modifies an existing file, promotes it to issue #1, and clicks Start Code Review:
He clicks the Refresh View button and sees that the code review is in Draft state, and the PulseUno button is enabled. (You might need to allow a few moments for the code review to be created):
Logan clicks the PulseUno button, logs in to PulseUno, and the code review is displayed:
Logan adds Emily and Joseph as reviewers:
Then he looks over his code changes:
Finally he clicks Publish. The review is now In Review, and that state is reflected in the associated AccuWork issue.
The review is now routed to Emily and Joseph for review. It will appear under My Work | Reviews: Waiting on review for both Emily and Joseph. If email notifications have been enabled, they will receive an email notifying them that a review has been published for their review.

PulseUno Documentation

To learn more about PulseUno, refer to the online help -- available through the question mark icon in the upper right corner of every PulseUno web page -- or view the information directly at:

http://myserver:8080/pulse-doc/AccuRev_MF_Pulse_User_Guide.pdf

PulseUno Code Review FAQ

This section presents answers to some frequently asked questions about PulseUno Code Review.

Q: Who can start (or update) a PulseUno Code Review?

A: Any user who can access the depot, stream and/or issue can start (update) a Code Review.

Q: How can I tell who created (or updated) my Code Review?

A: In the Activity section of the review, you can see who committed what changes to the review:

In this case, Emily started the code review, and the author of the transaction was Tony. The code review was then updated by Logan, and the author of that transaction was Lindsay.

Q: When adding reviewers to a Code Review, why don’t I see all AccuRev users listed?

A: AccuRev users must have logged into PulseUno at least once to be available as a reviewer. It’s possible the user you are looking for has never logged into PulseUno. A PulseUno administrator can see which users have logged into PulseUno.

Q: Can Code Reviews contain changes from multiple users? How can I tell which user made which change? If there are multiple contributors, who is the owner of the review?

A: Yes, PulseUno Code Reviews can contain changes from multiple users (just as an AccuWork issue can contain transactions from multiple users). The author of the change will be listed next to each transaction in the review:

The owner of the Code Review will be the author of the first transaction. In this case, the owner is Tony.

Q: How do my depot and element ACLs work with PulseUno? I don’t want users to see code that is restricted in AccuRev.

A: PulseUno Code Reviews respect all ACLs. Elements that are part of a review will not appear for users that do not have access. It is possible a review will appear empty if the user does not have access to any element. It is up to the author to select appropriate reviewers who have access to the elements of the code review.

Q: How are removed versions represented in a Code Review? We regularly remove versions of elements from our issue change packages, via the GUI and via the CLI cpkremove command.

A: When versions are removed from a change package, the elements do not disappear from the Code Review. Rather, they are marked as CPK Removed with a strike through the element name. Removing a version constitutes a distinct transaction in the Change Package History, and it is represented as a distinct changeset in the PulseUno Code Review.

Q: Does the “Code Review” tab in the AccuRev GUI’s Preferences dialog pertain to PulseUno Code Review?

A: No, the GUI preferences for Code Review relate only to Crucible Code Review (a third party product). There are no GUI preferences or settings relating to PulseUno Code Review (a product that is bundled with AccuRev 7.3 and later).

Q: In the Requests section where I see information about my issue, what issue fields are displayed? Can I change which fields are displayed?

A: The Requests section displays information about the associated issue. It also contains a link to open the issue in the WebUI. The issue information that is displayed comes from these four default schema fields:

These defaults are specified in the following properties defined in <ac-install>/pulse/conf/startup.properties:

accurev.request.title.fieldname=shortDescription accurev.request.body.fieldname=description accurev.request.createdby.fieldname=assignedTo

You can specify different issue fields (except for issueNum) by editing the startup.properties file. For example, if your company prefers to display the user who created the issue rather than the user to whom the issue is assigned, you can just change the last line shown above to:

accurev.request.createdby.fieldname=submittedBy

Note: These settings are global for PulseUno and must be made by a system administrator. They are not specific to an AccuRev server or to a depot.

Q: How can I control the voting on reviews and whether reviews are automatically approved or rejected?

A: PulseUno defines four different “rules” to control this logic. PulseUno administrators can configure different rules for different depots. The four rules available are:

defaultRule.js- approve/reject based on first reviewer’s opinion

leadsOnly.js - approve/reject based on first lead reviewer’s opinion

majorityDecides.js- approve/reject based on majority of reviewers’ opinions

allMustApprove.js- approve if all reviewers like it (i.e., approve); send for rework if any reviewer doesn't like it (i.e., requests changes)

Q: How can I use the Code Review state to control which issues get promoted through my stream hierarchy?

A: For streams that have workflow rules defined, the Code Review state can be incorporated into stream entry or exit rules in order to restrict issue promotion to only those issues that have passed code review.

The Code Review state can also be queried in the server_preop_trig trigger to restrict issue promotion.

GUI: Filtering Active Issues by Field Values

AccuRev 7.3 allows you to filter active issues so that you can quickly focus on the issues that interest you. The AccuRev GUI has a new Search button in the Active Issues views that enables filtering of active issues tables by field value:

In the Active Issues tab or in the Stream Browser’s Active Issues default group, clicking the Search button displays the Search Condition Filter dialog. There you can enter a search condition based on any issue field that is displayed in a column of the issue table:

When you click the Search button in the dialog, the GUI displays only those issues that satisfy the specified condition. The search condition is displayed above the table:

If you click Search again, you can refine the search by specifying an additional search condition:

You can click Refine Search to further refine your original search, or you can click New Search to start a fresh search using just this new search condition.

To end the search and return to seeing the full issue table, just click the Clear button:

GUI: Filtering History by Stream

Another new filtering option available in Release 7.3 is the ability to filter a History table by stream. The File History and Depot History views in the GUI include a new Filter by Stream dropdown that lists all the streams that are referenced in the full (unfiltered) History table. If you select a stream in the dropdown, the GUI displays only the table rows for versions in that stream. This allows you to more quickly find transactions that interest you.

Filter by Stream can be used in conjunction with the History table’s comment filter (the filter control labeled Filter Table) to zero in on specific transactions:

Clicking the Clear button or Refresh View clears the table’s comment and stream filters. Changing the number of transactions or the user or action filters for the History view also clears the comment and stream filters.

GUI: New Operations for Snapshot Streams

The 7.3 GUI now supports the frequently used commands Show Active Issues and Show History for snapshot streams. These commands are available in the stream context menu, as well as in the Actions menu in the Stream Browser toolbar:

Show Active Issues for Snapshot Streams

The Show Active Issues command answers the question “Was issue X fixed in this particular stream/release?” If you execute Show Active Issues for a snapshot stream, the GUI displays an Active Issues tab that lists all the issues that were active in the snapshot stream’s backing stream at the snapshot’s basis time. This tab is just like the Active Issues tab for a regular, dynamic stream; you can click on an issue in the top pane to see the contents of the change package in the bottom pane. You can also open an active issue to see what its contents were at the snapshot’s basis time.

Notes:

The Stream Browser does not display Default Group icons for snapshot streams.

In the Active Issues tab for a snapshot stream, the Open Issue command in an issue’s context menu is replaced by Open Historical Issue. Also, the tooltip for the Open button is “Open Historical Issue” instead of “Open Issue”.

If you execute Open Historical Issue, the GUI labels the issue tab with the issue number followed by “(hist)”, and it displays the snapshot stream’s basis time in the lower-right corner. These serve as reminders that you are looking at the issue’s contents as they were at a time in the past; field values may have changed since then.

Show History for Snapshot Streams

For users who do not use change packages in AccuRev, the Show History command answers the question “Was this fix included in the snapshot?” Executing Show History for a snapshot stream shows you the transactions that were executed in the snapshot’s backing stream up until the snapshot’s basis time.

GUI: Demote Locks

Release 7.3 extends the lock command to control Demote operations, in addition to Promotes, include/exclude, and the ability to modify the stream’s settings.

The CLI lock command has two new -k options to prevent demote-to and demote-from actions:

-kdt option: Prevents demotes to the stream. Versions cannot be added to the stream’s default group via a demote from the backing stream.

-kdf option: Prevents demotes from the stream. Versions cannot be removed from the stream’s default group via a demote from the stream to a child stream or workspace.

With no –k option at all: Creates an “all” lock, which prevents demotes to and from the stream, promotes to and from the stream, purge, incl/excl/incldo, and chstream operations on the stream.

In the GUI’s Stream Browser, the Locks dialog contains two new checkboxes for Lock Demotes To and Lock Demotes From the stream:

Demote locks are visible in both the GUI and the WebUI:

GUI: Displaying Third Party Issue IDs

When working in a depot whose schema defines a third-party issue field (via the 3pty ITS Key dropdown in the Schema Editor), users can now specify preferences about when and how third party issue IDs are displayed in the GUI:

The Display Third Party IDs preference indicates which IDs should be shown when the GUI displays issue IDs in a non-tabular format, e.g., in AccuWork tabs and Version Browser issue boxes. (In tables of issues, the column headers indicate the kind of issue IDs that are shown.)

If the Display Third Party IDs checkbox is checked and an issue has a third-party ID assigned to it, then the GUI displays the third party ID for that issue; otherwise, the GUI shows the issue’s AccuWork ID.

If some issues have third party IDs and some do not, it can be hard to know whether the ID you see is an AccuWork ID or a third party ID. The AccuWork Prefix and Third Party Prefix preferences address that problem. Users can specify different prefixes that will distinguish AccuWork IDs from third party IDs.

Here is an example that shows how types of issue IDs are distinguished by their prefixes (or lack thereof):

GUI: Transaction Details in the Annotate Tab

In Release 7.3, the GUI’s Annotate tab makes additional information available to the user. The tooltip for each line in the Annotate view now displays all the version information that is visible in the GUI’s Version Browser: transaction information, including real version numbers and comment text, and change package information. The tooltip appears if you hover the mouse over the “Trans. #” column of the table, and it disappears after about five seconds or if you move the mouse out of the transaction column.

The tooltip can be configured to display either just AccuWork issue IDs, or both AccuWork issue IDs and third party ITS keys. You can configure this with the AccuRev GUI preference called Display Third Party IDs. (See GUI: Displaying Third Party Issue IDs ).

If the Display Third Party IDs checkbox is unchecked, issue numbers are displayed in the Annotate tooltip as a single line starting with the prefix “Issues:”, followed by a comma-delimited list of AccuWork issue numbers. For example:

Issues: 30724, 31989, 40028

If Display Third Party IDs checkbox is checked, issue numbers are displayed in the Annotate tooltip as a single line starting with the prefix “Issues/3rd-Party Keys:”, followed by a comma-delimited list of AccuWork/third-party ID pairs. For example:

Issues/3rd-Party Keys: 30724/49115, 31989, 40028/31729

(AccuWork issue 31989 has no associated third-party key in this example.)

Note: Prefixes can be configured for the AccuWork and/or third party issue IDs using the AccuWork Prefix and Third Party Prefix fields in the AccuRev Preferences dialog.

New Unix Extras: rsyncAccuRev and autoRestoreAccuRev

Release 7.3 includes two new Unix tools that make it easier to backup and restore an AccuRev server: rsyncAccuRev and autoRestoreAccuRev. These tools can be found in <ac-install>/extras/unix/bin/.

rsyncAccuRev

rsyncAccuRev allows an AccuRev administrator running on a Unix/Linux OS to back up an AccuRev Server or AccuRev Replica either to a remote machine or to a local file system on the same machine. Backing up to the same machine does not provide good disaster recovery, unless the backed up drive is removed and stored elsewhere or it is backed up itself. Backing up to a remote machine is more useful; the remote machine could be a file server that itself is backed up, or it could be a test or hot fail AccuRev server.

Connections to a remote server are via ssh(1). The machines involved should have already exchanged ssh keys in order to prevent prompts to enter passwords. (Search the web for “ssh key exchange” to get further information about this.)

How to Use and Set Up rsyncAccuRev

Start by copying the file <ac‑install>/extras/unix/bin/rsyncAccuRev to a directory that is already in the Linux/Unix OS user <ac-user>’s PATH. Then run “rsyncAccuRev ‑m”. This will output a man(1) page detailing the tool’s functionality, use and configuration.

As with other AccuRev-provided scripts, there is a section of the file that you can customize; dee the CUSTOMIZE ME section and the variables with the setting of “change me”. You can also choose to set the variables via the command line, or more conveniently by providing an input file. In this last method you would run “rsyncAccuRev -c yourLocalConfigurationFile” to run a backup. Example input files are found in <ac‑install>/extras/unix/. The files named rsyncAccuRev‑local.cnf and rsyncAccuRev‑remote.cnf can be copied and modified for your site’s configuration.

At execution time, if any variable is still set to “change me”, the rsyncAccuRev script exits without creating a backup.

Sample Output

Here is a sample of output from the command: rsyncAccuRev ‑c rsyncAccuRev-remote.cnf ‑m(The text on the right side explains each line of output.):

Fri Jun 15 08:54:00 EDT 2018 -"Run Time Configuration" Configuration AccuRev 7.2 (2018/04/24)
  ACCUREV_ROOT : /opt/accurev == Where AccuRev is installed
  BACKUPserverUser : acserver == User running the backup on this machine
  BACKUPserverType : remote == Type of backup
  BACKUPserverMachine : 192.168.49.82 == Machine to backup to if BACKUPserverType = remote
  BACKUPserverDirectory : /AccuRev-backup == Destination file system of the backup
  BACKUPmetaDataFilename: backup-5-Friday.md == AccuRev backup filename
  BACKUPincludeCNF : true == Include the acserver.cnf and acclient.cnf files?

autoRestoreAccuRev

autoRestoreAccuRev can be used in conjunction with rsyncAccuRev. It enables an AccuRev admin to automate the restoration of an AccuRev backup file that rsyncAccuRev has created and pushed to a remote test/fail-over/disaster recovery (DR) machine.

When autoRestoreAccuRev detects a newly created PostgreSQL custom database dump file in the ac-install>/storage/site_slice/backup directory, it executes the following sequence of steps:

Shut down the AccuRev client process
Restore the PostgreSQL database dump file
Reconfigure the PostgreSQL parameters for the test/fail-over/DR machine
Start the AccuRev client
Run “accurev info” and “accurev show streams”