archimatetool / archi-modelrepository-plugin

coArchi - a plug-in to share and collaborate on Archi models.
153 stars 52 forks source link

Allow working on models based on repositories having the same name #104

Open samperd opened 5 years ago

samperd commented 5 years ago

User Story

As an Archi User I want to import multiple forks of a repository into an Archi Collaboration workspace So that I can make edits to one fork, while monitoring and managing another fork

Current issue

If I fork a base repo (eg https://github.com/canada-ca/architecture/network/members) to my own user space (eg https://github.com/samperd/architecture) then I can not import both of these into my workspace because the following directory is found to be non-empty

C:\Users\USERNAME\AppData\Roaming\Archi4\model-repository\architecture

Implementation details

C:\Users\USERNAME\AppData\Roaming\Archi4\model-repository\REPOSITORY

C:\Users\USERNAME\AppData\Roaming\Archi4\model-repository\USER-OR-GROUP\REPOSITORY

This should mean that multiple forks will not collide

jbsarrodie commented 4 years ago

@Phillipus I have the same issue/request for two reasons:

My suggestion would be to simply use a UUID for the local folder name, this would be an easy solution to avoid "name collision" (and this folder name never appears in UI as the real model name is used instead).

Phillipus commented 4 years ago

Will investigate options in the next coArchi coDing sprint.

jbsarrodie commented 4 years ago

BTW, It would be good to allow users to create folders and move local repositories in them when needed. It used to be possible in the early (POC) version of coArchi but has been remove after.

This would allow users to better organize their local list of clones (I know some people who have more than 50 local models in their workspace).

Phillipus commented 4 years ago

We need the organisation that we have in jArchi.

jbsarrodie commented 4 years ago

We need the organisation that we have in jArchi.

Yes, except that the model/git repository itself cannot be renammed

jbsarrodie commented 4 years ago

I'm copying what I wrote on #133 which duplicate this issue

When importing a remote model to the workspace while the target folder already exists, we get this kind of "Folder is not empty" error: image

I think we should manage this in a more user friendly way.

I can see two strategies:

  1. Keep current behavior but use the FQDN or the repo instead of only the repo name. This would lead to more unique folder name and would solve the root cause.
  2. Change the behavior so that when this error is raised, we ask the user if he/she wants to cancel or continue. If he/she wants to continue, then we add some randow text at the end of the folder name to be created.

The first option seems easier to manage, but the second has the advantage to allow someone to import a model more than once. Of course this should not be done unless you have a very specific need (TBH, the only use-case I see is us trying to simulate several people working on the same model, but for this I usually manually change the folder name anyway).