Xlinks break when their target repository is renamed
Repository A has an xlink to repository B. Repository B is renamed to C. When downloading the content of repository A to a workspace, there is an error, because the xlink points to a repository B that is no longer accessible under that name, even though it still exists.
I know you rarely change repository name, but it happens. You can of course fix all xlinks after you do that, but you won't fix the history. So if you attempt to download a historical changeset of repo A, you won't get its whole content.
Don't you think it would be safer to use repo's unique identifier in xlink definitions instead of name? However, I wouldn't change the existing PlasticSCM GUI or CLI for defining/editing xlinks in any way. Instead I would expect repo name to be translated to a unique identifier when defining an xlink, and to be translated back when didplaying its definition to the user.
Mariusz Schimke
shared this idea
As Mario pointed, we’ll close the suggestion. Maybe we can relive it in the future :-)
-
Patrik Påhlson
commented
The thing with Plastic was that you really didn't need to plan ahead compared to ancient tools like VSS. The problem is a bigger issue with nested repos like "level 1/level 2/level 3 (xlink)", which I like a lot.
-
Mariusz Schimke
commented
Seems there's no perfect solution, so let's forget my suggestion. As long as it is possible to create a branch from a historical changeset and then correct invalid xlinks, that will solve the problem. Unless you don't know the new names of renamed repositories, of course :-). You could store name history of a repo somewhere, so it can be used in such cases as a hint for the user.
But I guess you have more important tasks to do than that, so let's close the topic. Sorry for bothering you. I didn't realise its not that easy to solve the issue I mentioned.
-
psantosl
commented
Replicated repos don't have the same GUID, since they don't have to be identical (we allow partial replication among others). Objects inside it can have the same GUID (since they're identical).
Not sure if we have a good solution here. I'll give it a second thought.
Anyway, is this a common practice?
-
Mariusz Schimke
commented
The thing is that my knowledge on PlasticSCM use cases is still too narrow. For example I haven't used replication so far and I don't know its details. I will have to try it first to understand the problem better.
But isn't repo's GUID identical across all replicas? I'm just wondering why repos can't be looked for by GUID.
-
psantosl
commented
I understand your point here, but the solution is not so obvious.
We can't use the repo GUID for several reasons.
We heavily use Xlinks and replica. Suppose this scenario:
Your repo 'code' points to "components" and "graphics".
Then you replicate the 3 repos to your laptop.
It still works because it looks for the repos "by name", it won't obviously look for repos "by GUID" or it wouldn't work.
We could look up by GUID when you use "not relative server" Xlinks (you don't mark the 'relative server' tick), which means they are actually pointing to given server instead of 'the same server where the repo is'.
BUT, exactly the same issue can happen if instead of renaming your repos you go and change the server IP and you're not using 'relative server'.
We 'could' let the user set the xlinks by GUID instead of name in order to solve scenarios like yours, but I guess it is all about planning what you need, and when the structure changes there can be affected components.
We could also use something like 'try by guid if you can't resolve by name', but I'm not 100% sure it is valid.
Thoughts?