Create a query to select the desired issue record, as described in Selecting Issue Records with a Query. For example, to select issue record #472 from the Problems depot, create this XML document:
1 == "472"
accurev xml -l myquery.xml > issue472.xml
Change the top-level XML <issues> start-tag to <modifyIssue>.
Include the issueDB attribute in the start-tag:
<modifyIssue issueDB = "Problems">
At the end of the file, change the </issues> end-tag to </modifyIssue>.
Remove the entire <transNum> element.
Change the values of one or more existing fields.
If you wish, add new field values, using the discussion in Creating a New Issue Record as a guide.
Note: Starting in Version 4.6, the XML output file from Step 2 uses UTF-8 encoding, but the input file in Step 4 is interpreted as US-ASCII. Any non-ASCII characters in the file must be coded in decimal entity notation — for example,   .
accurev xml -l issue472.xml
When you submit the <modifyIssue> data structure to the AccuWork CLI, it modifies the specified issue record. As when you create a new issue record with the AccuWork CLI, field validations are not applied.
To verify the new record’s contents, submit the original query again:
accurev xml -l myquery.xml
By default, AccuRev resets any unspecified fields in the <modifyIssue> text file to their default values. For example, if your original text file included a <platform> element specified like this:
but this element is omitted from the text file that you submit using the
accurev xml -l command, the value for the Platform field for that issue record is reset to blank (i.e., unspecified).
You can use the replaceAll= attribute of the <modifyIssue> element to change how AccuRev updates issue records specified in the <modifyIssue> text file as follows:
<modifyIssue issueDB = "Problems" replaceAll="false">
If you set
replaceAll="false", AccuRev updates fields using the values specified in the <modifyIssue> text file; any fields that are not specified in the file retain their existing values. Returning to the previous example, if you set
replaceAll="false" and omitted the <platform> element from the <modifyIssue> text file, its value would remain All.
<modifyIssue issueDB = "Problems" replaceAll="true">
This is the default behavior described above. You do not have to explicitly set
In addition to changing field values of individual issue records, you can use bulk update to update multiple issues with the same changes to one or more fields. For example, you can use bulk update to change the value of the Status field to Scheduled for the issue records you specify.
To use bulk update, you use the XML to specify:
The records you want to update
The fields and values that you want to change
Returning to the previous example, if you wanted to change the value of the Status fields for issues 72 and 73 to Scheduled, and add a comment to the Description field, your XML might look like this:
<modifyIssue issueDB="accurev" replaceAll="false">
<description fid="16">Needs to be fixed ASAP</shortDescription>
Instead of using a <modifyIssue> document to change an existing issue record, you can use it to create a new issue record. This is useful for copying issue records from one depot to another. For example, you might use a <queryIssue> document, as described earlier, to retrieve the contents of an issue record from depot Problems, in the form of an <issues> document. As described in Step 3 above, when you change the <issues> tag to a <modifyIssue> tag, specify a different depot:
<modifyIssue issueDB = "Problems_Public">
In this example, the issue record will effectively be copied from the Problems depot to the Problems_Public depot. Make sure the target depot exists and has the same schema as the source depot.
The <modifyIssue> technique is also useful for making copies of the issue records that act as change packages, and for replicating issue records between different AccuRev sites.
Note that a new issue record created with <newIssue> always gets assigned the next available issue number; by contrast, a new issue record created with <modifyIssue> gets the issue number specified by the <issueNum fid="1"> subelement:
An issue record with this number must not already exist in the target depot, but there is no other restriction. It’s perfectly OK for most issue numbers to be unallocated.