On Fri, 21 Jan 2005 12:37:08 +0000, Will Dean <svn@indcomp.co.uk> wrote:
> If the process isn't running, you can't open the pipe (or if it was already
> open, writes and reads to the pipe fail with an error).
>
> Currently if the read or write fails, I just close the pipe.
> Before any status fetch, I verify that the pipe was opened - if it isn't,
> then I try and open it. So far, this doesn't require any timeouts.
>
> What I was thinking of is that if this 'open' fails, we start the
> process. We could either then poll for opening the pipe (which would need
> a timeout), or just not bother, and require that the user F5's again, to
> have another go at connecting.
I guess a one second waiting for the process (timout) would be best.
Even if the first request for a status fails, the next one more likely
will then.
> I was just expecting to start it when it was first asked for (though we
> could *also* auto-run it at boot time, to reduce delays the first time an
> explorer window is opened.
That would definitely be a good idea.
> >What about having the status cache implemented as a windows service?
>
> I suspect that the only advantage of having it as a windows service would
> be that it could run when no-one was logged on. In exchange for this
> (questionable) benefit, we would suddenly have a whole load of extra
> complication. It would possibly run as a different user to the shell, which
> might be a security issue I'd rather not deal with.
Yes, it would be a security issue. So called priviledge escalations
might be possible.
The advantage of a service isn't just that it's loaded before someone
is logged on. It's also a way to reliably (without users being able to
interfere/disable it) start it automatically. Every other method is
easy for a halfway experienced user to remove (autostart, registry,
...).
But that's something we can decide later.
> I currently just store svn_wc_status_t (I don't deep-copy 'entry'), which
> is 32 bytes. This is enough to do icon overlays and some of the
> column-provider columns, but not others.
>
> Deep-copying 'entry' is a bore, and I would probably do something like
> you've done in the shell extension, and just pick out the bits which are
> needed.
>
> As you say, this would start to make the per-file storage larger.
I've seen that you haven't changed the column provider yet to use your
new process. As soon as you do, you'll have to store more status info
for each entry (e.g. the URL) and the memory use will increase
slightly. But I don't think it will increase a lot.
> >Since the cache has an IPC interface, a simple "cache status"
> >dialog/property page could ask the cache process for specific
> >information like memory use, number of hold files, ...
>
> Yes, someone else suggested this. I'm torn as to whether it's easier to
> add more U/I to (for example) TortoiseProc and IPC the data accross, or
> whether it's better to add U/I to the cache itself.
>
> Last night I thought the latter was better, but I'm being turned towards
> the former...
If we ever(?) want to start the cache process as a service, then the
UI has to be in TortoiseProc. A service never should pop up an UI for
security reasons.
> >As you already mentioned, that can't be done unless we provide two
> >different extension dlls - one for the overlays/columns and one for
> >the property page.
>
> But that wouldn't be a bad thing, really, would it?
Not really. It would require a lot of rewriting the existing code, but
that's all.
> >One problem we might encounter with this approach which I haven't
> >mentioned yet:
> >You can't fetch the status while another Subversion process is
> >accessing the files (e.g. for an update/commit/...). This wasn't a big
> >problem with the current approach, since once you start
> >TortoiseProc.exe, the explorer already fetched the status and shows
> >the overlays. It is however a problem if you have multiple instances
> >of explorer open showing the same working copy folder and then you an
> >update/commit/... - then sometimes even with the current approach the
> >overlays get lost (showing "unversioned") because the working copy is
> >locked.
>
> Right. Does svn_client_status return a specific, easily detectable error
> in this situation?
Yes. But that error can also happen under other circumstances, so it's
not 100% sure why the error happens.
> >Can you commit what you already have so far? I'd like to have a look
> >at it and help out where I can...
>
> I'll commit it into the WillDev branch. I'd welcome comments, but please
> don't commit anything in there without talking to me first, because it
> might well cause conflicts...
>
> It's very rough....
Looks very good so far. I'll have a closer look this weekend.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 21 15:42:03 2005