> -----Original Message-----
> From: Stefan Kueng [mailto:tortoisesvn_at_gmail.com]
> Sent: Monday, December 15, 2008 10:16 AM
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: Question:is it possible to change the icon of a file
thathas
> been changed in the repository
>
> Gleason, Todd wrote:
>
> > I was going to say something similar. I wonder if anyone thinks
> > CommitMonitor functionality should be integrated into TortoiseSVN
(never
> > enabled by default though). It seems to me that people would think
it
> > was a cool feature, turn it on, get annoyed when their icons started
> > changing to indicate "remotely modified" (or "remotely locked"
even),
> > and then turn it back off.
> >
> > Besides, to implement it would mean a lot more TSVN icons.
>
> Might be possible, yes. But there are a lot of issues to handle:
If you were going to do this (and I doubt it's worth doing myself) then
here are my suggestions:
> * CM monitors URLs. How would you map those urls to working copies?
I think you end up with some data structure pain here. So your WCs have
the WC->URL mapping inside them. I'd probably use this to construct a
reverse mapping (URL->list of WCs). There is ample opportunity for this
to get out-of-date, which might require detecting when the WC changes
and cleaning up. I see this as fairly problematic in a native
environment like C++ (it would still be error-prone even with garbage
collection).
The upside is that if you allow monitoring on a per-URL basis as CM
does, users can leverage this to configure which WCs have commit
monitoring, and which don't. That's a nice "for free" feature.
> * what overlay should be shown if a file is modified locally but also
> has remote modifications?
As I alluded to, "a lot more TSVN icons". I imagine the icons would get
combined in some way. Maybe you reserve the left half of the icon's
color for local, and the right half of the icon's color for remote.
Whatever you do is probably going to look hokey to somebody.
> * how would you explain that the remote overlays are not reliable?
They
> can't be updated in real time (CommitMonitor only checks in specific
> intervals)?
Neither are the local overlays perfect (some users have more problems
than others, though in my experience 1.5.3 works a lot better than 1.4.x
did). It's going to be an FAQ.
I would also enable configuration of the specific intervals inside the
TSVN configuration dialog so that at least some users realize there's a
polling model in place (enable that configuration whenever somebody
turns on commit monitoring, and at least some users will get the clue
that it only updates every n minutes).
> Not to mention the big slowdown which would occur because of this: it
> would require a *lot* more string-comparisons ans interprocess
> communications.
Yes, there would need to be a lot of thought put into keeping
performance sane, and doing as much as possible outside Explorer. You
might even limit it so only users running TSVNCache can enable commit
monitoring. Not that I understand the specific architecture of Explorer
or TSVN.
Performance-wise, I'm not convinced this would hurt too bad on the
client. As long as the commit monitoring (network activity especially)
runs in the background, the rest mostly depends on the amount of repo
activity. No idea about the server impact though.
Regardless, it seems like there's enough involved with this feature, and
enough room to destabilize the code base that I wouldn't undertake it
without a lot of interested users.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=984619
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-15 20:19:09 CET