Assuming of "Their" doesn't have effect, if an element is deleted remote

[eugen-eugen]

coArchi Version

0.9.4

Archi Version

5

Operating System

macOS

Description

During the "Refresh Model" operation, a conflict occurs when a user has made local changes to an element that has already been deleted by another user in the shared model. This conflict is correctly detected and prompted, as shown in the screenshot below:

Problem:

When resolving this conflict by selecting "theirs" (i.e., choosing the server version, which implies discarding local changes), the local modifications to the now-deleted element still remain in the model. This contradicts the expected behavior.

Expected Behavior:

Choosing "theirs" should:

Remove the local version of the element.

Discard any local changes made to it.

Ensure the element is no longer present in the refreshed model.

Actual Behavior:

The element remains in the local model even after selecting "theirs".

The user's local changes are preserved silently.

No warning or indication is given that the element wasn’t removed.

Impact:
This behavior is confusing and unintuitive. It may lead to inconsistent models and miscommunication between team members. Users assume that "theirs" will always override local content, but that is not happening in this case.

Suggested Fix:
Ensure that when "theirs" is selected in this specific conflict scenario (element deleted remotely, modified locally), the local version is deleted accordingly — or at least show a warning if it cannot be deleted automatically.

Steps to reproduce

Steps:

1. Create a simple model. Add an element to it, for example, a Business Actor named "ba1".
2. Add the model to a workspace (ws1). Use the Collaboration command "Add Local Model to Workspace and Publish" to publish it to a remote Git repository.
3. Import the model into another workspace (ws2). Use the Collaboration command "Import Remote Model into Workspace".
4. Modify the model in workspace ws1: Delete the element "ba1" from the model.
5. Use the Collaboration command "Publish Changes" to push this deletion to the remote repository.
6. Make conflicting changes in workspace ws2: Modify the element "ba1" (e.g., rename it or change its properties).
7. When attempting to refresh in ws2, a merge conflict occurs. You are prompted to resolve the conflict — choose "Theirs" (i.e., accept the changes from the remote repository where "ba1" was deleted).

Observed Issue:

Despite choosing "Theirs", which should delete the element "ba1", it still remains in the model. This indicates that the deletion in the "theirs" version is not being correctly applied, even though it should have removed the element.

[Phillipus]

Yes, that does seem to be the case. It's been this way since forever, but I can't remember if there is a reason for this.

@jbsarrodie Do you know if this was intentional or an oversight?