wlinks in real world

[DaSHTech]

I am trying to figure out if my xlinks are working properly or if I just don't understand. first off, I am using the cloud edition, so don't know if that makes a difference as all my workspaces basically check directly in to Plastic Cloud.

I have two workspaces named mainpg and tools. In the mainpg workspace, I have an wxLink set to my tools workspace.

I have made a few changes along the way to some text files in tools while I was in the mainpg workspace but haven't seen the tools changeset move. 

    Question 1: Do I need to switch over to my tools workspace to commit the changes separately, then update the link manually in mainpg to reflect the proper changeset? 

When I do the above and switch between historical changesets, the wxlink appears to update with the rest of the changeset items.  However, when I check the actual tools folder, no changes have been made to the files. updating the workspace has no effect either.

Question 2: is there something wrong here or am I just not doing it correctly?  I love Plastic for my mainpg workspace and it has worked flawlessly through many branches and merges. I just don't seem to have any luck with the wxlinks.

Thanks in advance,

Steve

[psantosl]

Hi Steve

 

first quick answer: xlinks have nothing to do with workspaces. Do you mean repositories ?

[DaSHTech]

Maybe this will help - I have two snapshots of my workspace, the first is my current changeset, the other is from an old branch that is basically an old maintenance version of the app that gets occasional maintenance updates.   In the current version, the link to jpatools is at changeset 40, the old version it's at 2. That's all as expected. However, when it's displaying changeset 2, I check the actual tools directory and the files are still dated this month and have the most recent changes, which is obviously a problem for a build expecting 2017 files.  I hit "update workspace" 

 I guess I don't see a lot of difference as my workspaces seem to be local copies of repositories, but hopefully this gives a clearer picture.

 

[calbzam]

Hello,

In the below screenshot you have an Xlink pointing to the changeset cs:2@JPATools. If you switch your workspace in the parent repo to this changeset, the content of the "JPATools" folder will be cs:2@JPATools.

You can create a new workspace directly pointing to the "JPATools" repo and switch to the changeset 2. The content of this workspace should be same as the Xlinked in the parent repo.

If it doesn't work as expected, we may need to arrange a meeting as I haven't seen a problem with this feature in the past.

Regards,

Carlos.

[DaSHTech]

so, I need to move over to the jpatools repo and switch manually as I move around in the main repo? Because as I switch now, those are the two views I get: the top is my latest changeset (cs784) in main which shows cs40 in tools and the bottom is a different branch (cs785) in the main repo which shows cs2.  The directory for the jpatools repo is unaffected when I switch, even if I update workspace. Is that expected behavior?  

I assumed that if I switched to the bottom branch that shows cs2 in tools, that it would update the tools workspace to cs2. I don't seem able to affect the jpatools repo unless I switch to it separately.

[calbzam]

Quote

so, I need to move over to the jpatools repo and switch manually as I move around in the main repo?

No, when you switch to a changeset in the parent repo, it will load the Xlinked changeset in this parent repo. You don't need any extra operations. The directory for the jpatools repo should be loading the content of the XLinked changeset.

Quote

I assumed that if I switched to the bottom branch that shows cs2 in tools, that it would update the tools workspace to cs2.

You are right, it should be loading cs:2@JPATools

If you don't see this behavior we would need to get connected and take a look. I haven't seen issues with this behavior in the past.

Regards,

Carlos.

[DaSHTech]

OK, I feel like a dummy and figured out how this works now. I thought the wxlink was purely symbolic and actually manipulated the tools directory, but now I see that it created a subdirectory within my main program directory and is updating there. I guess that makes sense as it makes it less likely that I might lose something in that original repo if there are uncommitted changes. This tools directory hasn't changed much over the years, so I've never noticed how this works as my main program references the jpatools directory directly, thus ignoring my wonderful wxlink directory. Time for some refactoring!

[calbzam]

Great! Thanks for the update