Xlink target histories

[wyattetal]

It appears that XLinks hide the change histories for their targets.

 

For example:

If Repo "GLOBAL" xlinks to REPO_A, then inspection of GLOBAL's branch explorer does not show changes that were made to REPO_A unless those changes happened to have been made to a GLOBAL workspace. Changes made to a workspace instantiating REPO_A are apparently not visible when launching branch explorer for a GLOBAL workspace.

 

What is the best way (if any exist) to assemble an aggregate change history for all of the assets below GLOBAL, including xlinked repos such as REPO_A?

The fallback that I have discovered is to systematically view, in turn, the branch histories for each x-linked repo below GLOBAL, but this is of course not an aggregated report.

[manu]

Hello!

 

when you xlink a repository you aggregate the remote repository dir/files hierarchy, you can edit then and commit, eve, you can even branch (auto branch expansion).

 

As you an see you can work in a component based methodology.

 

On the other hand the branch explorer is mono-repository. You can open extra branch explorers from the repositories view or right clicking the xlink directory from the items view, it's under the "Repository" menu.

 

I can think in a few scenarios where you would like to open remote branch explorers (or have them aggregated) but I don't see myself using it everyday, maybe once every 2 weeks or so, can you give me an example?

[wyattetal]

Yes, the files themselves in the workspaces are encapsulated within the folder created by the xlink during workspace creation.

However, I have noticed that branch exploration for xlink targets is hidden when exploring xlink parents.

 

Example:

I create a workspace for REPO_A, create a branch we will call RA_CHANGE, make some changes and merge this branch back into the main trunk of REPO_A.

I then create a workspace for GLOBAL, update to latest, including pointing GLOBAL's xlink to REPO_A to the latet changeset discussed immediately above.

If I branch explore GLOBAL, the only change I will see related to any of this is the xlink change. I will not see the RA_CHANGE branch.

For that I must access the branch explorer (or changeset history etc) for REPO_A.

This is the case even if GLOBAL existed prior to making changes specifically to REPO_A.

 

I presume you are acknowledging this with the summary: "branch explorer is mono-repository".

 

If I am correct in this observation, then this opacity is a good reason why xlinks are best avoided for associating closely related files.

Put another way: Just because a subdirectory is good idea for the code on disk does not mean an xlink is a good idea, because it separates the histories for its targets and makes it more difficult to view that lifespan as a system.

 

Is there some history tool (a report or some other) that crosses these xlink boundaries, or is a decision to xlink effectively a decision to partition historical information?

[manu]

Example:

I create a workspace for REPO_A, create a branch we will call RA_CHANGE, make some changes and merge this branch back into the main trunk of REPO_A.

I then create a workspace for GLOBAL, update to latest, including pointing GLOBAL's xlink to REPO_A to the latet changeset discussed immediately above.

If I branch explore GLOBAL, the only change I will see related to any of this is the xlink change. I will not see the RA_CHANGE branch.

For that I must access the branch explorer (or changeset history etc) for REPO_A.

This is the case even if GLOBAL existed prior to making changes specifically to REPO_A.

 

Yup, you are right, if you double click that changeset you are diffing the xlink creation. You didn't perform any other change, just adding a new xlink. You didn't perform the REPO_A merge by the time you created that changeset, so nothing more is displayed. Showing more information would be wrong.

 

A different story is when using the GLOBAL repository you perform the merge and you create changes under the REPO_A, you'll be able then to see everything as one, because you created those changes by the time 

 

If I am correct in this observation, then this opacity is a good reason why xlinks are best avoided for associating closely related files.

Put another way: Just because a subdirectory is good idea for the code on disk does not mean an xlink is a good idea, because it separates the histories for its targets and makes it more difficult to view that lifespan as a system.

 

Well, it separates the history when they evolve independently, history is closely linked when the GLOBAL repository evolves modifying the REPO_A repository.

If GLOBAL is not going to be modifying REPO_A then GLOBAL xlinks to REPO_A repository are just static pointers and remotehistory (remote xlinked cset comment, remote xlinked cset owner, remote xlinked cset changes) can be easily fetched using queries.

[wyattetal]

Thank you. We will search docs on remotehistory.

[manu]

Please don't hesitate to answer if you have any suggestion. I really appreciate it, I'm just trying to give my point of view and explain how and why it works in the way it does.