Simultaneous modifications to x-linked Repo causes information loss?

[wyattetal]

Information loss resulting from simultaneous modifications to an x-linked Repo

 

If workspaces for two repos (A & make simultaneous changes to x-linked repo C, the following documentation link

https://www.plasticscm.com/documentation/xlinks/plastic-scm-version-control-xlinks-guide.shtml#Chapter3:XlinkExpansionRules

seems to indicate that repo B should be referenced somehow in the changeset triggered by the modification made from workspace B.

 

Instead, the changeset triggered by the modification from Repo B is recorded in Repo C as if it had been produced by work in Workspace A. Even after both the A and B branches are merged back to their parents, Repo B references are nonexistent. Why is all of this the case?

 

Another (perhaps fundamentally relevant) observation that begs explanation: After making the modification in Workspace A that, via x-link, triggered branch and changeset creation in Repo C, renaming the branch in workspace/repo A does NOT result in the equivalent change to Repo C. This behavior indicates that x-link triggered modifications to x-link targets are not so much dynamic references but rather static historical notations. As such, the implication is that x-links themselves are not references but rather a mechanism for shorthand notation specific to the exact moment of activity. In more concrete terms, this suggests that information is ignored or lost across x-link boundaries in certain situations, specifically interactivity between contending or even cooperating source branches and renaming of source branches at later points in time. One point worth noting in this example is that none of the repos (A, B nor x-linked C) ultimately contain an aggregated history of the changes that took place. If someone wanted to examine this history, they would need to conduct a systematic examination of all three repos and reconcile the overall evolution manually. Is this an accurate appraisal?

 

How do you recommend that the above insights guide decisions about x-links when organizing source code in plastic?

[manu]

Hi,

 

let's start with the first question.

 

Information loss resulting from simultaneous modifications to an x-linked Repo

 

If workspaces for two repos (A & B make simultaneous changes to x-linked repo C, the following documentation link

https://www.plasticscm.com/documentation/xlinks/plastic-scm-version-control-xlinks-guide.shtml#Chapter3:XlinkExpansionRules

seems to indicate that repo B should be referenced somehow in the changeset triggered by the modification made from workspace B.

 

Instead, the changeset triggered by the modification from Repo B is recorded in Repo C as if it had been produced by work in Workspace A. Even after both the A and B branches are merged back to their parents, Repo B references are nonexistent. Why is all of this the case?

 

Why do you say the changeset created at the C repository (by the Workspace working with B repository) is having information about the Workspace A? Where do you see it?

 

Now, the second one

 

Another (perhaps fundamentally relevant) observation that begs explanation: After making the modification in Workspace A that, via x-link, triggered branch and changeset creation in Repo C, renaming the branch in workspace/repo A does NOT result in the equivalent change to Repo C. This behavior indicates that x-link triggered modifications to x-link targets are not so much dynamic references but rather static historical notations. As such, the implication is that x-links themselves are not references but rather a mechanism for shorthand notation specific to the exact moment of activity. In more concrete terms, this suggests that information is ignored or lost across x-link boundaries in certain situations, specifically interactivity between contending or even cooperating source branches and renaming of source branches at later points in time. One point worth noting in this example is that none of the repos (A, B nor x-linked C) ultimately contain an aggregated history of the changes that took place. If someone wanted to examine this history, they would need to conduct a systematic examination of all three repos and reconcile the overall evolution manually. Is this an accurate appraisal?

 

How do you recommend that the above insights guide decisions about x-links when organizing source code in plastic?

 

I don't see drawbacks here, if an A/B repository branch gets renamed (frequently renaming branches is not a good habit) the xlink will continue working, not only loading the external repository C content but also the checkin expansion rules will keep working. So tracking history down or reviewing changes from the source repositories will continue working.

 

The xlink object targets changeset GUIDs so it doesn't matter if the target branch gets renamed or if the local one does, the content will be always be found as long as the target changeset is not removed.

And regarding the checkin operation, the branch expansion rules will also be aware of the branch renaming operation for both source and destination branches. They will get dynamically updated if one or the two branches are renamed, allowing the checkin operation deliver the changes to the right branch.

 

You are right about the fact that renaming a branch will not trigger the rename operation for the target branch, but we didn't consider it a must while developing it.

[wyattetal]

How do I post screenshots?

[manu]

By opening the "More reply options" page. There you'll be able to attach files and images.

[wyattetal]

[manu]

Please, if you could write a small description about the scenario that would help.

 

Are they about the rename branch questions? I can't see it.

Are they about the Repo A info logged in a Repo B changeset that modified a Repo C file/directory through an xlink? I can't see info about this either.

 

Step_31.png: Can't understand what you explain in the comment. I guess it's a repo C branch explorer, can't know for sure, info has been removed.

Step_32.png: Plastic will automatically create branches based on the target changeset location. That means.

 

1) If you create an xlink from the "/main" branch of repo A to a changeset on the "/main" branch of repo C the child branches will be created based on main.

 

A@/main -> C@/main

A@/main/task001 -> C@/main/task001

 

And you won't need to create C@/main/task001

 

2) If you create an xlink from the "/main" branch of repo A to a changeset on the "/main/sub_brach" branch of repo C the child branches will be created based on "/main/sub_brach" for the target repository.

 

A@/main -> C@/main/sub_brach

A@/main/task002 -> C@/main/sub_brach/task002

 

And again, you don't need to manually create "C@/main/sub_brach/task002".

[wyattetal]

Both screenshots are of Repo C.

* The leftmost circle (changeset 0) is the initial create. no issues there.

* The following circle (changeset 1) is also part of the setup. I added a single text file (FileC.txt) to RepoC and labeled from Repos A, B and C.

 

The other three circles are the important ones:

 

* Changeset 2, (with the current changeset symbol) was created in RepoC by Plastic when Workspace A made a change to FileC. Plastic auto generated the branch in RepoC, named it after the initiating branch in RepoA "JIRA_SAN-3: Repo A does some work", and created a corresponding expansion rule in RepoA's xlink to RepoC.

 

* Changeset 3 is highlighted in the first screenshot. It was created by plastic's auto generated expansion rule when RepoB's Xlink was edited and set to changeset 2. Note that the only mention of RepoB and RepoB's branch for the corresponding changeset is in the comment. If you quickly looked at the branch explorer view you would think that RepoA was responsible for the highlighted changeset 3. But it isn't; Repo B is. Why didn't the change initiated by RepoB, which is working with a branch called "JIRA_SAN-4 Repo B does some work" result in the creation of a new branch from changeset 2 with the same name as the one in RepoB?

 

* The second screenshot highlight's changeset 4. Changeset 4 is what we would have expected to result from the change to RepoC initiated from RepoB in its corresponding branch, "JIRA_SAN-4: Repo B does some work". However, we had to create the branch "main/JIRA_SAN-3/JIRA_SAN-4: Repo B does some work" manually in RepoC.

 

To put it another way:

Changeset 3 is how plastic handles a change to RepoC made by RepoB if RepoB's xlink points to the very latest changeset within RepoC. Information has been lost because RepoC's branch explorer view indicates that changeset 3 was made by the branch corresponding to RepoA's work. "JIRA_SAN-3: Repo A does some work"

 

Changeset 4 is the result of the following:

- We manually created a branch in RepoC and associated it with RepoB's Jira Task. The resulting branch in RepoC is main/JIRA_SAN-3/JIRA_SAN-4: Repo B does some work".

- We then edited RepoB's xlink to RepoC to use changeset 2 (changeset two is the current changset of RepoC in the screenshot)

- BUT... before closing the edit xlink dialog for RepoB, we deleted the auto generated changeset, which was destined for JIRA_SAN-3, and added a manually defined expansion rule that was destined for JIRA_SAN-3/JIRA_SAN-4. Question: Why did Plastic create a branch in RepoC when RepoA made a change but did NOT create a branch in RepoC when RepoB made a change?

 

 

Is this is still unclear? Should I post detailed step by step instructions for how to reproduce?

[manu]

* Changeset 2, (with the current changeset symbol) was created in RepoC by Plastic when Workspace A made a change to FileC. Plastic auto generated the branch in RepoC, named it after the initiating branch in RepoA "JIRA_SAN-3: Repo A does some work", and created a corresponding expansion rule in RepoA's xlink to RepoC.

 

Everything right here.

 

* Changeset 3 is highlighted in the first screenshot. It was created by plastic's auto generated expansion rule when RepoB's Xlink was edited and set to changeset 2. Note that the only mention of RepoB and RepoB's branch for the corresponding changeset is in the comment. If you quickly looked at the branch explorer view you would think that RepoA was responsible for the highlighted changeset 3. But it isn't; Repo B is.

 

Only changing the repo B xlink target to a newer one will not create a new changeset in repo C. It only creates one in repo B to store the new target but nothing should be created at C.

 

Why didn't the change initiated by RepoB, which is working with a branch called "JIRA_SAN-4 Repo B does some work" result in the creation of a new branch from changeset 2 with the same name as the one in RepoB?

 

I need to know the expansion rules to answer this question.

 

 

* The second screenshot highlight's changeset 4. Changeset 4 is what we would have expected to result from the change to RepoC initiated from RepoB in its corresponding branch, "JIRA_SAN-4: Repo B does some work". However, we had to create the branch "main/JIRA_SAN-3/JIRA_SAN-4: Repo B does some work" manually in RepoC.

 

I have just followed your steps and I get the "JIRA_SAN-4" created automatically as you expected. Not sure what extra operations are you are doing to achieve that behavior.

 

 

To put it another way:

Changeset 3 is how plastic handles a change to RepoC made by RepoB if RepoB's xlink points to the very latest changeset within RepoC. Information has been lost because RepoC's branch explorer view indicates that changeset 3 was made by the branch corresponding to RepoA's work. "JIRA_SAN-3: Repo A does some work"

 

Ok, so you didn't only change the xlink target? Did you make an actual change from B touching C content?

If you change the repo B target xlink to a changeset that is in the repo C "JIRA_SAN-3" branch Plastic will store new B changes inside the repo C "JIRA_SAN-3" branch. This is how it works, if you are not comfortable with the default expansion rule you can edit and change it.

 

So at this point I deduce your repo B expansion rule for repo C xlinks at the repo B main branch is:

 

Source branch                                                       Destination branch

/main@B@localhost:8087                                     /main/JIRA_SAN-3@C@localhost:8087

 

Because you changed the target changeset to point to changeset 2 that lives inside "/main/JIRA_SAN-3@C@localhost:8087"

 

And here as I said all the changesets produced at /main@B@localhost:8087 will be stored at "/main/JIRA_SAN-3@C@localhost:8087"

When you create a main child branch called "JIRA_SAN-4" in repo B this will happen:

 

Source branch                                                       Destination branch

/main//JIRA_SAN-4@B@localhost:8087                  /main/JIRA_SAN-3/JIRA_SAN-4@C@localhost:8087

 

 

Source branch                                    Destination branch

/main@B@localhost:8087                  /main/JIRA_SAN-3@C@localhost:8087

[wyattetal]

Step by Step with screenshots and questions at end....

 

Step 1: Create Repo A

Step 2: Create Repo B

Step 3: Create Repo C

Step 4: Create workspace for Repo C, add FileC.txt,  Checkin (RepoC changeset 1)

Step 5: WXLink RepoA to RepoC:changeset1; Checkin; Update Items

Step 6: WXLink RepoB to RepoC:changeset1; Checkin; Update Items

Step 7: Create the following JIRA tasks: SAN-5_WSA changes, SAN-6_WSB changes

 

Step 8: In RepoA, create a branch from main for SAN-5_WSA_changes. Note that no new changesets have been added to RepoC. Note that no expansion rule has been added to RepoA_WX_RepoC

 

Step 9: From Workspace A, add the following line to FileC.txt:

"This change was made by workspace A. It is expected to be changeset 2 for RepoC, and be placed in a branch named for "SAN-5_WSA_Changes"."

The change has not affected RepoC, which looks the same in branch explorer as it did in step 8.

 

Step 10: Checkin; Inspect branch explorer for RepoA and RepoC. Inspect RepoA_WX_RepoC. Note that Plastic has autogenerated both of the following:

* a new branch in Repoc "JIRA_SAN-5", presumably named after the iinitiating branch in RepoA.

* an expansion rule to that new branch

 

Step 11: In RepoB, create a branch from main for SAN-6_WSB_changes. Note that no new changesets have been added to RepoC. Note that no expansion rule has been added to RepoA_WX_RepoC

 

Step 12: From Workspace B, Edit RepoB_WX_RepoC to point to changeset 2. In the Edit Xlink dialog, Plastic auto generates an expansion rule with destination branch JIRA_SAN-5 (the branch that is associated with RepoA's work)

 

QUESTION 1: Why was this expansion rule generated at this point in time?

QUESTION 2: Is this a bug? The rule is apparently the reason RepoB's contributed changesets to RepoC are placed in the branch associated with RepoA's work.

 

[manu]

QUESTION 1: Why was this expansion rule generated at this point in time?

 

Because you are editing an xlink in a branch where no expansion rule is defined.

The system gets by default the destination branch which contains the destination changeset. Which makes sense since new changesets created at the remote repository will have that target changeset as its parent.

 

QUESTION 2: Is this a bug? The rule is apparently the reason RepoB's contributed changesets to RepoC are placed in the branch associated with RepoA's work.

 

I don't consider this a Bug, if you don't like the default rule that's why you can delete it and create a new one. You will say that you'll need to manually create the target branch. Yes, in this case it has to be done like that.

 

Notice this is a really weird way to use xlinks and it' shouldn't be the regular way to use them.

 

What would I do in your case.

 

I need to start working in a child-repoB-branch but having the xlinked changes from the child-repoC-createdByA-branch.

 

Open workspace B

Items view -> Right click the xlink you want to update -> Repository -> View branch explorer.

Right click the changeset you want to start loading -> Merge

Complete the merge & Ci.

 

Outcome: 

 

1) The "/main/SAN-6_WSB_changes@B@localhost:8087" branch has a new changeset as the result of the merge.

2) The "/main/SAN-6_WSB_changes@B@localhost:8087" branch is now loading the content you wanted.

3) The new changesets you'll create at the "/main/SAN-6_WSB_changes@B@localhost:8087" branch under the C xlink will be stored at "/main/SAN-6_WSB_changes@C@localhost:8087" branch. A good expansion rule has been created.

4) The C repository branch explorer records the merge operation and you easily understand the new "/main/SAN-6_WSB_changes@C@localhost:8087" branch is now loading the "/main/SAN-5_WSA_changes"@C@localhost:8087" changes. Much easier to understand what's going on and you can also use CherryPicking if you want.