Copied From

QName: f:copied-from

Indicates that a specific revision of a node received its content from a copy operation. This feature can be used to identify points in the node history where a copy operation occurred from a different node (even a node from a different branch or repository entirely) into the current node.

The Copied From feature tracks a single property called sourceRef which is a node reference to the node on the source branch that was the source for the copy operation.

The Copied From feature is automatically applied by the system as needed during import and copy operations. It does not need to be manually applied.

In addition, the Copied From feature will not be carried forward on subsequent saves. It is meant to tag a single version of the node in the node's changeset history and is used to track the influence of a source node on that version (indicating a copy operation took place).

Configuration

<thead>
    <tr>
        <th>Property</th>
        <th>Type</th>
        <th>Default</th>
        <th nowrap>Read-Only</th>
        <th>Description</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>sourceRef</td>
        <td>text</td>
        <td></td>
        <td></td>
        <td>
            The reference to the source node that was copied into the target node.
        </td>
    </tr>
</tbody>

Usage

Suppose you have an existing node on the master branch. You then do the following:

1. Create a new branch called branch1
2. On branch1, you make a few edits
3. Meanwhile, on the master branch, you also make a few edits
4. You copy the node from branch1 back to master.

After you do this, the changeset history across these two branches might look something like this:

                         cs0
                          |
                         cs1
                          |---------->    (create branch)
                          |          |
                          |         cs2'  (branch edit #1)
 (master edit #1)        cs2         |
                          |         cs3'  (branch edit #2)
                          |          |
                          |         cs4'  (branch edit #3)
                          |          |
                         cs3 <--------    (merge back)
                          |
                          |
                         cs4

If you were to pull back the version history for the node on master, it would look like:

cs4, cs3, cs2, cs1, cs0

If you were to pull back the version history for the node on branch, it would look like:

cs4', cs3', cs2'

If you were to read the node from changeset cs3, you would see that this version of the node would have the f:copied-from feature on it. It has this feature because this version of the node is the merge of the cs4' version (from the branch) into the cs2 version (from master).

The f:copied-from would point to a sourceRef which is the node version for cs4'. In addition, the node at cs3 would have a parent changeset ID that points to cs2.

In other words, because in step #4 you copied the node from the branch back to master, the node on master was effectively updated. It was overwritten. This is the same as if you were to go to the node on master and make any other edit. It's a write operation and not a merge. A merge is a different thing.

Because you copied, the node on cs3 is an update and has a single parent (cs2). However, it automatically keeps track of the fact that you copied from somewhere by applying the f:copied-from feature. This provides you with a way to figure out, after the fact, that a copy operation occurred (as opposed to a direct update). You can use this information to work backwards and discover the content that was copied.

Note: if you were to merge instead of copy, the f:copied-from feature would not be applied. Instead, the version at cs4 would have 2 parent changeset IDs instead of one. In addition, the node would have the key _system.mergeChangeset set to cs4'.