Setting or method to point X-links always to latest rather than fixed changeset?

Unity Services
,
1

Hi there,

We are trying to move a project over from Perforce that has shared code and assets between two repos but it seems that there is no way to get x-links to always point to latest - and for us this will likely create a mess with team members potentially forgetting to manually update the reference each time they commit etc.

There is an older PlasticSCM forum post from years ago here:

…where a developer of the tool suggested this fix would be in shortly - 11 years ago - but it still isn’t. Is there any chance this might be added as an option or setting in the GUI so that we can automate that all pushes to - and references to - an xlink location, will always be latest by default?

It seems it can be done by CLI currently, so the functionality is there but not something we can set so that team members wont shoot themselves in the foot / disrupt the project by forgetting to set the Xlinks to latest manually each time they make a change.

Any help or pointers much appreciated!

2

HI @RichM

Regarding the Xlinks, they are static pointers. You cannot configure them to “point to the head of the branch”. Otherwise, it won’t be following the static configuration of a changeset.

This is something that is possible per design in Gluon. In the Plastic GUI workspaces, they are always pointing to a specific changeset/branch. In Gluon you can load file revisions from different changesets.

I cannot either be done via CLI. Could you share the steps or guide you are following?

3

OK, so there’s the more detailed explanation of our situation:

We have two Untiy projects, one for the main game, and one for level editing/modding tools. We need to share some art assets, and some components, between the two projects and both need to match. This far we’ve been using Perforce, and have used their import+ mapping option to get that folder from the game project and map it into a folder inside the level editing project, writable from both sides, and that has worked great over the past years

However, we would be interested in moving to UVCS, but would need to come up with some kind of workable solution to sharing that folder between the two projects.

We moved the shared folder to be in a repository of it’s own, and set up wXlinks to map that into a folder in each project. So now submitting anything from project A will correctly submit them to that shared repository, and also does update the wXlink in project A to point to latest changeset. (menaing it’s not as fixeThe problem is that the wXlink in project B will not get updated the same way, so submitting any change to either project where any file might be in that wXlinked folder would require people to afterwards open the other workspace, edit the wXlink manually, submit that change, and pull the latest changes. If that’s not done the result is both a pretty cryptic error message (for anyone not familiar with what’s going on behind the scenes here), and also a situation were it’s possible for someone to edit files (including scenes, art assets, etc), which are supposed to be locked, and then ultimately being unable to check in their work in the end and loose it instead.

If we were only concerned with using the CLI client we could set up some scripts to check what the latest changeset number is on the other workspace, and then edit that wXlink automatically. However we need a setup that’s actually usable by non-programmers, like artists and designers, so it needs to be doable from the GUI client, and not require a checklist of extra manual steps in a different workspace for each check in.

We are very much aware that wXlinks pointing to a specific version is what makes sense in the most common use cases for this kind of feature, like linking to a stable version of a library etc, but are hoping there would be some way to make this work for our studio’s needs. It looks like some Plastic dev 11 years ago recognized this type of situations as a valid use case, and 2 out of the 3 changes needed at that time to make it less of an issue have indeed been implemented, but the last one, being able to configure an wXlink to point to head of the branch was never done. If the option of just setting the wXlink to point o head is for some reason strictly not agreeable to you, then just having some solution for automatically updating that wXlink in the other workspace to point to the correct version (like it already does for the workspace where you submit the change) would work fine for us as well.

4

Hi, in the following blog post, we explain how you can configure the Xlinks in a scenario where you have some shared repo/library/code that needs to be used by two different main/parent repos. Please let us know if it helps in your environment: Plastic SCM blog: How to share an engine repository between different video games

5

We are aware of how you set up basic library sharing between repositiories and how to xLink to a fixed version of that library, unfortunately that’s not what we are after, as said we can’t allow the two projects to be on different version of that shared repository and need them to always match, as they are not two separate games using some shared engine, but two parts of one game.

6

Sorry for reviving an old post - but were you able to solve this issue?

I’ve tried looking at the old Plastic SCM blogs, but they’ve all been replaced with basic Unity docs.

@carlosalba1985 - have the Plastic blogs been archived anywhere for reference?

7

Sadly, No.

We ended working around it instead by reorganizing our projects and development workflow to work with this limitation compared to what we did with Perforce previously.

It’s not really optimal and causes some headaches and makes certain things pretty hard to deal with and require more manual work than before, but since people in the studio have in general been happier with UVCS and the painful parts are mostly limited to me only (and I still prefer them over maintaining our Perforce server), we decided to stick with UVCS regardless.

That being said, the staff were very helpful and tried to help me create a scripting solution to this. Didn’t work out for our exact needs in the end but might do it for you…

(also for the old blogs etc, you might be able to find them with the Internet Archive’s wayback machine…)

1 Like
8

Thanks for the reply.

Yeah, it feels like I might also just have to work around the limitation too.

And re: old blogs - I did check the wayback machine, but they keep diverting away as well :man_facepalming:

Thanks for your help!