XLink updated in branch - merge impossible ?

[PeterThierolf]

Hi folks,

 

I have the following scenario :

 

I merged a big, partly breaking change in a shared library repository.

Then I created a branch in a dependent repository that has xlinked the shared library, in the branch I updated the xlink to link the latest version of the shared library, fixed all breaks (including minor updates to the shared library).

 

Now I want to merge this dependent project branch back into the mainline.

 

The merge doesn't seem to get that I updated the xlink, instead it shows me all the individual files that the changed xlink contains as changed files. I have not tried to commit this merge result - changed xlinks show up very differently in the pending changes view so I fear it will not do what I intended to do.

 

So what to do now ? Should I cherry pick my local changes, then change the xlink in the mainline ? How should I proceed with the automatic branch in the shared library ?

 

This is a very common scenario for me - can I set this up in a more clever way so that merging works in the future ?

[calbzam]

Hi,

 

If you are using Xlinks (for instance your shared library),  we recommend to perform the commits from the parent repository. I mean we don´t recommend to perform commits directly in the Xlinked repositories.

 

This way, if you perform changes in some Xlinked content, the Xlink target will always be automatically updated to the last commit of the shared library. You will not need to manually update the Xlink to get the last changes.

 

If you are manually editing the Xlink target, remember to commit the changes after editing the Xlink. After that, if you update wour workspace, you will see the content of the edited Xlink.

 

 

Regards,

Carlos

[PeterThierolf]

I see.

A problem is, that when checking in the edited Xlink, the project is broken for anyone else.

 

I actually was able to resolve the problematic situation in three steps, but it was quite inconvenient.

 

If the shared library gets a breaking update I can do that through a using repository, but If I do that I get only that one project right, to get others fixed I need to edit their xlink, commit that edit and break the project for everyone else through that.

 

I would very much prefer if editing an xlink, keeping the edit checked out but than updating the workspace would get the files from the checked out, edited xlink.

This way I could edit the xlink, fix the project, check in. Everything fine.

 

I went with the branch to integrate the breaking changes only because I had to checkin the xlink to get it reflected in the workspace.

 

 

If you think of updating some unreal engine you licensed, it might take days and some coders to get the codebase working with the update. You don't really want to checkin the xlink for everbody before doing the update, but a shared library kind of only makes sense if you think multiple projects.

 

 

By the way - fixing my situation was basically to edit the xlink in the main line before trying to merge. That worked but, of course, broke the project as long as the merge lasted. Still a lot better than just checking in the breaking xlink in the mainline as the merge was rather short than.

 

 

Cheers,

 

Peter

[calbzam]

Hi,

 

I understand your scenario. If you need to edit a Xlink to perform a change in shared library, and you don´t want to disturb other developers, I would do it in a different branch. If you don't really want to checkin the xlink for everbody before doing the update, use a different branch for it.

 

 

This way, you would edit the Xlink, update your workspace and after performing the changes, merge  these changes to your main branch. 

 

 

 

Regards,

Carlos

[PeterThierolf]

Well, we are back to the initial post now because that is *exactly* what I tried to do.

 

However, it doesn't work to merge an edited xlink back. The merge engine doesn't recognize the xlink, doesn't update the xlink, updates all the individual files in the xlinked repo.

 

Cheers,

 

Peter