Release Notes

Xlinks: Fixed a couple of scenarios where the user couldn't perform changes inside an xlink due to the "Can't perform a checkout in an edited xlink" error.

FIRST SCENARIO

The first one was related to checking-in partial changes inside an xlink.

Having the following structure in the workspace, where /xlink is an xlink :)

/xlink/foo.c

If we add a couple of files:

cm add /xlink/bar.c
cm add /xlink/qux.c

But we only checkin one of them:

cm ci /xlink/bar.c

We will not be able to checkout /xlink/foo.c or add a new file /xlink/aux.c

SECOND SCENARIO

This happens also when checking-in changes inside an xlink but in a different way.

Let's suppose that we are committing some changes inside and xlink and there are not new changes in the xlinked repo so it can be correctly completed. BUT, someone created a new changeset in the parent repo so a merge is needed in order to complete the checkin for the parent repo although the changes inside the xlink where correctly checked-in.

At this point, we are in the same situation than in the previous scenario. We are not able to checkout or add any new file inside the xlink.



              

All platforms - Plastic, Command line client: When undoing complex locally moved changes, you could get the error "The item XYZ already exists!". That's been fixed. If you want a deeper explanation of the problem, continue reading!

Imagine this scenario - you have a deep tree structure and you do the following operations outside of Plastic SCM:

1) Rename a directory.

2) Rename a file inside said directory (from name A to B).

3) Move up a file deeper in the tree structure to be alongside the recently renamed file.

4) Rename the file you just moved to have the same previous name as the other file you renamed (from name C to A).

With a little diagram, we have transformed this (simplified):

 /a
 |- /b (1)
 |   |- fileA.txt (2)
 |   |- /c
 |   |   |- fileC.txt (3)
 |   |   |- some.txt
 |   |   |- more.txt
 |   |   |- files.txt
 \   \   \- here.txt

Into this:

 /a
 |- /x (1) (LM from /a/b)
 |   |- fileB.txt (2) (LM from /a/x/fileA.txt)
 |   |- fileA.txt (3) (LM from /a/x/c/fileC.txt)
 |   |- /c
 |   |   |- some.txt
 |   |   |- more.txt
 |   |   |- files.txt
 \   \   \- here.txt

…where numbers (1), (2) and (3) indicate the item correspondence (directory or file), and (LM) indicate the new status from said item.

Now, before doing further operations (undo, checkin, and so on), Plastic SCM needs to convert local changes to controlled ones. The problem was that, because of how Plastic SCM calculates precedence between local changes, it was trying to apply first the LM on item (3) instead of on item (2). An item with the same name and path already existed in the metadata (because changes on (2) were still to be applied), and the command execution failed. Now, Plastic SCM correctly calculates locally moved changes precedence in order to apply them in the right order.

This is a good moment to remember you that, for doing complex restructurings, you can use the GUIs or the command line client. Plastic SCM will update the metadata with each move, delete, and rename operations, which makes the process much less error-prone.