Hello,
After using upgraded v4.9 to deal with our working model, yesterday and today, I got the Model Error popup when saving, as attached.
Try to search those reference item by id in the model file / folder structure (in File Manager), but there're nothing in searching result.
Do you have ever met this issue? And is there any method to position one element base on their id# within Archi model?
Thanks greatly,
Xiaoqi
Is this a model that is shared in coArchi?
yes, Phil, we're using coArchi and I've upgraded plug-in to 0.8.0 accordingly.
Did you do any merging on the the model? What actions were performed?
Hi Phil,
Yes, after upgrading and working on the model, I tried to added some customized images using new Specifications Manager yesterday, then as attached, did merge with the central model (the central model was in the early Archi version built).
During yesterday Merge, there's one popup window asking to choose Own or Other, but there're empty content in both side, so in the "20f18c22" commit, we just choose default and continue, and then publish at "9dc626ce". This is one strange point observed.
Is that merging creating orphaned? I think I can try to reverse to earlier commit timestamp, but before reversing, would like to find a way to know what those "Profile Reference" referring to, then possible I can manually delete or correct those orphanes.
But within Archi, not able to search those specific ID. Or I miss some methods?
Thanks greatly, really need to solve this as I cannot save now.
Will try another way parallel, which is create one another branch from Master again, then try to work on that and see. (Just using this way I need to drop the new modeling work perform on current branch during today ;-()
Regards, Xiaoqi
Hi Phil,
I'm now trying to restore to earlier commits, when restoring to the latest one "9dc626ce", got same error, but the id # are all different.
Those errors are in 4 groups, each group has "Profile reference is orphaned" and "Profile has wrong concept type".
I tried using Export to Excel plug-in to export model and in the exporting, cannot find those 4 pair reference. Think as they're orphaned, they're not treated as inside of the model, so any exporting function will not include them.
Since restore to latest one commit is getting error, will continue to restore to further earlier ones, will see. (And, plan b, will to drop the current day's work and branching one new branch from Master later, hope that can be the working way)
p.s. although the id # are keep changing on those different error screen, but I think these 4 groups are talking the same orphaned reference. If there's one way can find out them, then I hope I can manually remove those orphanes.
Thanks a lot,
Xiaoqi
Hi Phil again,
Within my "problem" branch, I keep get that error even I tried to restore the several earlier commits in the history list, I think that still due to the error in the current timestamp commit version having prevent the "saving" then provent all other actions. Although it is looked like I restored, but actually it's still not working.
Thus I gave us to keep fixing the "problem" branch, ignore the new added elements today, and force switching to "master". Then from "master", create one new working branch. As that's inherit from "master" and "master" is at least in OK mode, I can now get one good working branch.
Later on, the only thing I can do will be delete that "problem" working branch.
Rethink what had happened from yesterday, I think it's quite possible happened on the incompatible features coming from Specifications added in 4.9.0.
Here are what happened in detail --
- I have v4.9.0, added several customized images in Specifications Manager, test on the "Grouping" notation, and use them to two views with showing the images in the group (as network segments), in my local model, it works perfect.
- Our "master" is maintained till latest commit by v4.8.1 tool version, I've synced and then merged to "master" with my new Specifications feature
- I invited one team colleagues for testing, he's still in v4.8.1, before he's upgrading, I asked him to do one sync to his local model to see what happened, since we have other colleagues are all in v4.8.1 still, when merging, he reported that "merge alert" (without any hints) pop up, then we choose continue
- Besides that, no other issue, then my colleague commits his on-hand work and merge to "master", at this time, still in v4.8.1
- During our co-working, as I reported in earlier question, as the model header of v4.8.1 has header version "4.6.0" and v4.9.0 has header version "4.9.0", on his last commit, the additional changes created due to this model header version # difference, we know this before, so we chose continue
- After that, my colleague did Archi tool version upgrading to v4.9.0
- Then after I synced his merged "master" and continue working today, I then realise I cannot save due those pop up error.
Now within the Xiaoqi-New branch, I found the Specifications Manager back to empty. So I suspect this new added features on Specifications may the root cause.
One hints is I actually created 3 customized images (although the error screen has 4 issue group of Profile reference, possible I did and remove one image), that is supported in v4.9.0; when my colleagues sync the model I merged into "master" to his local working model, the v4.8.1 Archi cannot recognized those new image features, then the only way is to break relationship of those elements/references from the model branch in his side, then when he merged back to "master" and I then synced back to my local, in my v4.9.0 those Specifications reference profile should still there but have no "linkage" to the model.
If this is the case, then I'll communicate with all of our rest of team colleagues (which has already informed), that they need to upgrade first before do any further processing (especially commit/sync/merge).
At the same time, before all team upgrading to v4.9.0, we'll not start utilizing the Specifications features, hope this can be the workaround shortly as those new features are so attractive and we'd like to adopt as early as possible.
Not sure my analysis is in the right direction, but this tought us the sensitivity of "backward-compatibility" is so important. I'll keep observing on my new created branch status.
Thanks,
Xiaoqi
Hi,
The issue is that when using coArchi, all users must have the same version of Archi (or versions of Archi based on the same version of the model format... which just changed with 4.9).
If you use 4.9, create and use specializations, each time someone publishes from an older version, it will remove specialization definitions and references. So at best you lose you work, and at worse this left some of your newly created elements 'orphaned'.
As, written on the forum some time ago, coArchi does not support Archi 4.9, so it must be used with care (everybody uses the same version of Archi and only one people manages specializations). And even in this case, there might be conflicts on concepts for which two people changed the specialization. In such case you'll see a conflict but won't be able to see the two different values for specialization.
Regards,
JB
Thanks JB, fully understand that the best situation is all users are in same version, but the reality is challenge, as we have more than 10 users in the team, we'll have to try fasten the shadow period.
However, for your comment:
Quotewritten on the forum some time ago, coArchi does not support Archi 4.9, so it must be used with care
I found the 0.8.0 coArchi has the Archi 4.9 as dependency, what's mean "not support"?
QuoteVersion 0.8.0 - October 12 2021
Handle Specialization types when loading and saving
Requires Archi 4.9
Thanks,
Xiaoqi
Hi,
Quote from: xiaoqi on October 15, 2021, 10:00:23 AM
I found the 0.8.0 coArchi has the Archi 4.9 as dependency, what's mean "not support"?
QuoteVersion 0.8.0 - October 12 2021
Handle Specialization types when loading and saving
Requires Archi 4.9
Let's say it like that: we don't support coArchi together with Archi 4.9 in production use. We've added only the very basic support to make sure people can experiment with it, but there's no support for conflict management and no anticorruption layer related to specialization definition or use. So depending on the case:
- If use coArchi in a single user setup (only to store versions of your model), it will work
- If you collaborate with people having another version of Archi, don't use the new features until everyone has the same version (allows a smooth transition period during which some people have 4.9 but don't use new features)
- If everyone has 4.9, and only one person is in charge of defining specialization, then it should work most of the time with no corruption. but if there's a conflict on a concept because two people decided to change the specialization set, you won't see the values in the conflict window and you'll have to pick one version randomly.
- Anything else will likely endup with a corrupted model in a short amount of time
@Phil: I think we should make it clearer in the coArchi section of the plugin page.
Regards,
JB
Quote from: Jean-Baptiste Sarrodie on October 15, 2021, 10:29:29 AM
@Phil: I think we should make it clearer in the coArchi section of the plugin page.
I've added a warning box and linked here.
Thanks JB for the summarizing, now it's quite clear. I think our aim is to move to all in 4.9 then carefully manage the usage of "specializations" within a team.
Also thanks Phil to add the warning box.
Hi Phil, JB,
Just to confirm my reading of this - if I don't use specialisations, then Archi 4.9.0 and coArchi 0.8.0 will work fine together in a collaborative environment as prior versions?
Dave
Hi,
Quote from: DaveVint on October 25, 2021, 16:12:35 PMJust to confirm my reading of this - if I don't use specialisations, then Archi 4.9.0 and coArchi 0.8.0 will work fine together in a collaborative environment as prior versions?
Yes, if you don't use specializations, everything else works as usual. Using custom image also works without issues.
Regards,
JB
Quote from: Jean-Baptiste Sarrodie on October 25, 2021, 19:14:10 PMHi,
Quote from: DaveVint on October 25, 2021, 16:12:35 PMJust to confirm my reading of this - if I don't use specialisations, then Archi 4.9.0 and coArchi 0.8.0 will work fine together in a collaborative environment as prior versions?
Yes, if you don't use specializations, everything else works as usual. Using custom image also works without issues.
Regards,
JB
Thanks JB!
We had this problem and the problem persisted even after removing Specialization features and bringing all Archi versions up to 4.9.1.
The solution was an update of the coArchi plugin to version 0.8 on all machines.
Hi,
Quote from: Thomas Rischbeck (ITMC.ch) on December 08, 2021, 08:59:13 AMThe solution was an update of the coArchi plugin to version 0.8 on all machines.
Indeed, only the latest version of coArchi includes the minimum support for Archi 4.9.x.
Regards,
JB
Quote from: Thomas Rischbeck (ITMC.ch) on December 08, 2021, 08:59:13 AMWe had this problem and the problem persisted even after removing Specialization features and bringing all Archi versions up to 4.9.1.
The solution was an update of the coArchi plugin to version 0.8 on all machines.
Saved my bacon. Thanks!
Hi! Is there any changes for better when using 4.10 with coArch 0.8.4?
BR,
Tomek