Show status of changes on remote and locally (without user action)

[Phillipus]

• Provide feedback about what's going on on the local clone vs remote. So this means (for example) changing model icon (in the Collaboration Workspace) when there are uncommitted changes, unpushed commits, available remote changes...
• We could start with providing feedback related to informations/status we already have (unsaved, uncommited, unpushed)
• Then we could add a manual way to do a git fetch and add feedback related to available remote changes
• Then do some git-fetch in the background.

[Phillipus]

Some git calls are expensive such as:

• git status (to check for pending commits and pushes)
• git fetch

If there are many local repos in the Collaboration Workspace and we use a background timer or Job to call these it could block the UI.

I thought that for a first implementation we might add a "Refresh" button to the Collaboration Workspace. However, this could be confused with the "Refresh" action on the model...

[jbsarrodie]

Maybe we should (again) think about saving a checksum (and size?) of temp.archimate file in the .git folder. It would then be easy to check if the model has been changed (so no need for a costly git status).

I guess that checking if HEAD is ahead of remote/master has no cost.

I thought that for a first implementation we might add a "Refresh" button to the Collaboration Workspace. However, this could be confused with the "Refresh" action on the model...

Just call it "Check for updates" ;-)

[Phillipus]

A checksum might be a good idea.

I've been running some experiments...

IArchiRepository#hasChangesToCommit() can do the git level call, but for this to accurately reflect changes in the git folder, we have to call GraficoModelExporter#exportModel() first to synchronize changes between the temp.archimate file and the xml files in the .git folder. So it really is an expensive operation to do in a background job. And it might collide with a user-initiated operation if it is run in the background (GraficoModelExporter#exportModel() would be the problem)

[Phillipus]

I've managed to write a checksum and compare with the temp.archimate file checksum. The issue is one of synchronising when the checksum is written. This could be on a commit, undo commit, abort published changes, and maybe more.

This creates one more problem in the job of keeping things in sync:

temp.archimate file xml files checksum file

So, at this stage I'm starting to wonder whether this is a good idea.

[Phillipus]

Before we can ascertain the status of commits we need to call GraficoModelExporter#exportModel(). However, this needs the IArchiMateModel to be loaded first. So this is not something that can be run in the background,

[Phillipus]

Implemented a background check for unpublished commits and for unpulled commits on the remote. This shows as overlay icons and tooltips in the Collaboration Workspace.

• Could use better overlay icons
• Background job for fetch runs every 20 seconds

[Phillipus]

This is not working on GitBlit repos.

It's not GitBlit. It's when a model is pushed from Archi to a git repo. It needs the tracked "master" branch set:

[branch "master"] remote = origin merge = refs/heads/master

Edit: fixed this now

[jbsarrodie]

I've tested and it and that fine.

My suggestion for overlay icons: use two arrow on the same bottom corner:

• one from top to bottom to show that there are new things on remote
• on from bottom to top to show that there are things to publish

Something like that:

[Phillipus]

I tried that icon idea, but you can't see it properly. Typical overlays for a 16x16 icon are 7x8 and can be positioned in each quadrant. I'll try something else...

[jbsarrodie]

I tried that icon idea, but you can't see it properly. Typical overlays for a 16x16 icon are 7x8 and can be positioned in each quadrant

No properly because of their small size or because you can't have two overlay icons on the same quadrant ?

If the last reason, then maybe something like that:

[Phillipus]

It's too small. You can't distinguish it.

How about using the icon itself and coloring certain parts of it:

[jbsarrodie]

Hmm. Maybe it's time to rethink those icons from the ground up and no more use those eclipse-ish ones.

In such case, we find an icon that can be used to convey the following ideas depending on context (and cumulative):

• Uncommited (local) changes
• Unpublished (local) changes
• Unsynchronised (remote) changes)

[jbsarrodie]

How about using the icon itself and coloring certain parts of it:

I've seen that you've included those new icons on the published release. This seems the better option for the moment, but I would finetune it:

• color the top ball for unsynchronised (remote) changes
• color the bottom left ball for uncommited (local) changes (when we'll be able to detect them)
• color the bottom right ball for unpublished (local) changes

[Phillipus]

Yeah, I put it out there unless we have something better. I can juggle the balls easily ;-)

[Phillipus]

Latest commits show the 3 colored balls.

And the Grafico export is triggered everytime the user saves the model. This last thing should be tested in case it slows down the save action.

[jbsarrodie]

And the Grafico export is triggered everytime the user saves the model. This last thing should be tested in case it slows down the save action.

Is it done in the background? If not I can already told you to disable it as I'm working on a model that takes a long time to be exported (approx 30sec).

[Phillipus]

It is done in a UIJob so it may be OK. Test it...

(30 seconds? Is that the Grafico export or the save?)

[jbsarrodie]

It is done in a UIJob so it may be OK. Test it...

I've just tested and this seems fine (in fact seems quicker than before, but I'm testing on Linux while I usually use this model on Windows).

(30 seconds? Is that the Grafico export or the save?)

I think it was mainly the time for JGit to compare HEAD with current tree and find changes to commit.

[jbsarrodie]

I've just tested and this seems fine (in fact seems quicker than before, but I'm testing on Linux while I usually use this model on Windows).

Just tested on Windows and this is really slower slower (12sec) and this blocks UI :-(

I'm opening another issue for that...

[Phillipus]

I'm opening another issue for that...

OK. Let's discuss there... ;-)