Files disappear after revert

[palota]

I use TortoiseSVN and TortoiseGit software which add commands to the context menu. If command "Revert" is used to discard changes, then the file disappears in xplorer2. I must always refresh folder manually.

[nikos]

autorefresh works most of the time. What's the change introduced by the Revert command? Is it just files changing their modification dates?

[palota]

1) file is deleted to recycle bin
2) new file is written to temporary folder
3) then it is moved from temporary folder to current folder
4) modification dates are changed

[nikos]

I just tried a simple revert command with TSVN and the file change was picked. Is there something special with your folder, e.g. is it on a remote server somewhere?

[palota]

There's nothing special with folder. It is on drive C.
It works if the same folder is opened in Explorer too. Then it is successfully refreshed both in Explorer and xplorer2.
It works if Overlay Icons status cache is set to Default in TortoiseSVN settings and process TSVNCache.exe is running. But I want to set overlay cache to Shell or None, because TSVNCache.exe is often slow.

[nikos]

if you want to beef up autorefresh, try this extra option
www.zabkat.com/blog/13Jul08-run-as-admi ... efresh.htm
(it isn't meant just for administrators)
note that this makes all refreshes a bit slower

[Kilmatead]

note that this makes all refreshes a bit slower

I was curious about this, as I have had this option ticked for the last few years (I unapologetically always run as Admin), so it seemed reasonable to wonder what actual delays might be entailed.

A quick, not especially "controlled" experiment seems to oddly contradict your assertion. I have a user-command which I use to "zero" the content of targeted files (for example, a media-file of 2GB is simply flushed to 0 bytes so I may keep the file itself, just discarding its content). Essentially, when this is applied, the command executes immediately, and the auto-refresh kicks-in as it has detected a change, both to the file-size itself and its modification date.

Normally, such a delta would be difficult to actually see, but as I use my Khronos plugin (no, this is not a shameless plug ) as an "age" annotator for files, it has consistently registered the above file-change as being around 150 to 170 milliseconds "old". In other words, I execute the command, the file is zeroed, and x2 refreshes the display triggering the plugin to update the displayed modification delta - in this case, as I said, around 150 milliseconds.

"So what?", I hear you sigh, with that tired but tolerant tone you adopt when Kilmatead is prowling the warpath again.

Well, since the above example is always consistent (and has been for a month now), I decided to disable this Alternative Refresh thing of yours just to see if there was any difference (admittedly, limited to just this specific datum), expecting (if anything) for the delta to decrease, if auto-refresh is supposedly slower with it active.

Instead, x2 started registering the refresh delta as being a full second out, instead of mere milliseconds, and this is actually a sense-detectable delay, as I'm used to the change being triggered instantaneously (well, within 150 mils, anyway), whereas a delay of a second can be a distinct pause.

So I did it again (using copies of the original files, in the same location), and again, and again... and again. Consistent deltas of 1 full second. Switching the Alternative Refresh back on, and the deltas immediately returned to 150-160 milliseconds.

I did the test 10 separate times each way, and each time when I was expecting a delay (active "alternate"), it was always faster, inactive "alternate" always being slower.

Like I said, though this test is not exactly empirically precise or under true controlled conditions (I can actually feel the disapproving ghost of Aristotle behind me ), the results do consistently show that it's always faster when it's supposed to be slower, and slower when it's supposed to be faster.

(As caveat, I am well aware that Windows modification timestamps are a faithless lot, subject to deviations in shell conditions like caching, drive-speeds, etc... but irrespective of that, my results are consistent and demonstrable.)

So... what gives? Not that I'm complaining, 150 milliseconds is always better than 1000 for an update, but your suggestion that auto-refreshes will take longer seems to be... the exact opposite of what occurs?

[nikos]

the "alternative" autorefresh does all the folder all the time (all the contents regardless of change). The "smart" refresh may do the same but if only 1-2 files change at a time, it only does these files that changed. If the folder is small, you wouldn't notice the difference

[Kilmatead]

Ah, an answer that only a mother could love.

That I obviously do notice (and can measure) the difference, and that the results seem antithetical to your premise is only more sugar on my corn-flakes. Since I've been using this setting... well, forever... and my first foray into not using it resulted in nothing but slower responsiveness (not lack of responsiveness, as might be inferred from Admin-vs-non-Admin) methinks the ghost in the machine is more my friend than yours.

No wonder computers never brought about the paperless office.

[nikos]

did I say that there is a delay of 0.5 second (default) where the "smart" system waits till it acts on the change?
when I say the alternative refresh is slower, I mean it makes the computer work harder
but your machine sympathy was never highly rated

[Kilmatead]

did I say that there is a delay of 0.5 second (default) where the "smart" system waits till it acts on the change?

Ah hah! So I wasn't just saying incantations to resurrect Aristotle for nothing! No, you neglected to mention that subsection of the fine-print.

I'm thinking that your original efficiency-modelling is a little long in the tooth these days - the firmware of disc-controllers (those little chips inside hard-drives which determine throughput-vs-latency) have, you know, improved substantially in the last 10 years? Not SSD's specifically, the hardware has improved across the board.

You know only too well how two well-meaning efficiency-models can cancel each other out, resulting in worse performance overall. How-or-never, I'll not convince a technophobe like you to appreciate the benefits of thrashing hardware to within an inch of its electron-migration, so I'll just sit back and flaunt my smugness until the robot-overlords whack me over the head with their malignant indifference to humanity.

At least I wasn't imagining things: The slower way is actually the faster way! Buckminster Fuller would be proud, even if Aristotle is mildly chagrined in the waning light of your Greek dominance over Western Civilisation.