Files in a controlled directory have icons indicating their status

[KristinaTaylor]

Demonstrate that Files that correspond to members of a sandbox have an icon indicating that they are controlled. (checkmark) Files that exist in a file system folder and are not yet members of a project have an icon indicating that they are new. (+) Files that have been deleted from the project have an icon indicating that they have been dropped. (x) Files that have changed locally or been moved (red !) Files that have been locked have an icon indicating that status (lock) Files that have been modified both locally and remotely, or have an unresolved merge have an icon indicating conflicted status. (! in yellow triangle) Ignored files are not decorated (including .pj) are not decorated.

There must be a gesture available to update the status of a file or group of files.

[bleskowskyPTC]

@KristinaTaylor, would like some feedback on this. The current implementation of icon drawing presumes that the versioned and modified icons are always available in the event that we need to fall back to another overlay if the primary one was not available/loaded. This seems like a good assumption to make and we should continue on this premise, therefore this table suggests the finalized overlay hierarchy for each file status we can encounter (basically, if the primary overlay is not versioned/modified, make sure the secondary overlay is). Let me know if the fall-back overlays make sense to you or you want to change them.

File Status	Primary Overlay	Secondary Overlay
Locked	locked - lock	versioned - checkmark
Incoming	conflict - ! in yellow triangle	modified - red !
Former Member	deleted - x	modified - red !
MergeNeeded	modified - red !
Modified, Moved, Renamed	modified - red !
Drop	deleted - x	modified - red !
Add	add - +	modified - red !
Member	versioned - checkmark

[gisraeli]

I don't know if incoming should be conflict or if it should only have that icon if it is modified and incoming

[KristinaTaylor]

I like what @bleskowskyPTC has laid out here. The ! in yellow triangle indicates that the user needs to do something before they can reliably work on this file, so I think the incoming/merge needed are good.

The secondary overlays are good too - no action needed, versus action needed.

[bleskowskyPTC]

I will make sure that the logic follows this then. It's mostly there, just need to add appropriately to the states we added more recently

[bleskowskyPTC]

@gisraeli made the point (and I agree) that we don't need an explicit gesture to update file statuses since this can be done by hitting F5

[KristinaTaylor]

:+1:

[bleskowskyPTC]

This has been merged and can be verified using build 1.0.41.0 or later. See overlay table above.

[bleskowskyPTC]

Note, @atusek and @flemingg, you might want to see pull and merge this one into your dev branches if you've been having issues with unordered sequence exceptions while debugging.

[bleskowskyPTC]

Some testing notes: It may be possible when you are verifying this that you see the secondary overlays rather than the primaries. This is due to hitting the cache limit for overlays (not as likely to happen on a fresh VM) and can be fixed by removing non-Tortoise overlay identifiers (ones that don't have "Tortoise" in the key name) from the following registry location: HKLM/Software/Microsoft/Windows/CurrentVersion/Explorer/ShellIconOverlayIdentifiers. Once explorer is restarted, you should see the primaries. You can export the ShellIconOverlayIdentifiers in regedit if you want to save the keys somewhere before you delete them. Conversely, testing that the secondaries work may be a little more difficult since the drawing of secondary overlays is based on whether or not the primaries are available (loaded by the dll), meaning in certain cases we could be seeing a mixture of primaries and secondaries, arguably non-deterministic. One way I can think of to force this scenario would be to remove all Tortoise overlay identifiers EXCEPT 1TortoiseNormal and 2TortoiseModified, since these are the only secondary overlays. Note that you would not be able to test MergeNeeded with this setup since it has no secondary, but presumably this has been tested for primary overlays. Unless there is an easier way of doing this (thoughts @gisraeli?) I'm not sure how worthwhile it would be to test secondary overlays.

[gisraeli]

This should either be tested in a clean VM or in by cleaning the registry as Blaise notes

[bleskowskyPTC]

Just to follow process, can someone add the "needs verification" flag fir this issue?

[KristinaTaylor]

Found during sprint review: modified locally should take precedence over incoming changes. As a result, red exclamantion mark should be used for marked for later merge, because it denotes further work that the user needs to do before submitting.

[bleskowskyPTC]

Updated precedence matrix above to show that NeedsMerge case show red exclamation mark as primary (and only) overlay, since PR #69 merged

[bleskowskyPTC]

This can be verified in build 1.0.63.0 or later

[sharonzhao]

Verified the primary overlay with build 1.0.64.0 in a fresh vm. Files with the following status show the correct primary overlay (see the above overlay table): locked, incoming, former member, modified, moved(defer), renamed(defer), drop, add, member.

The NeedsMerge file didn't show red exclamation mark, instead it shows the lock.

[bleskowskyPTC]

I think the issue with the NeedsMerge is that yes, it has a deferred merge, but the user also has a lock. Removing that lock should show red exclamation mark.

[sharonzhao]

That’s right. Red exclamation mark shows after I removed the lock. I guess I can pass it then☺

From: Blaise Leskowsky [mailto:notifications@github.com] Sent: March-02-15 5:10 PM To: PTC-ALM/TortoiseSI Cc: Zhao, Sharon Subject: Re: [TortoiseSI] Files in a controlled directory have icons indicating their status (#16)

I think the issue with the NeedsMerge is that yes, it has a deferred merge, but the user also has a lock. Removing that lock should show red exclamation mark.

— Reply to this email directly or view it on GitHubhttps://github.com/PTC-ALM/TortoiseSI/issues/16#issuecomment-76837381.

[sharonzhao]

After the lock was removed, the NeedsMerge shows red exclamation mark.

[KristinaTaylor]

Reviewed during sprint review.

[bleskowskyPTC]

Removed needs docs: documented in Alpha release User Guide