> I do wonder how this would impact TSVN or other GUI apps - how do they
> know if a directory is under version control? Does it even trigger if
> there isn't a .svn dir? Or, does it call some SVN APIs on every
> window change? I'm sure we could work with them to make sure that we
> don't screw them. I'd imagine for deep WCs, a GUI like TSVN might
> constantly be walking up the directory path to see if a .svn directory
> exists. I also don't know how well we'd handle excluded directories -
> i.e. user doesn't check in a certain sub-directory - it'd be nice to
> handle those efficiently as well without the time/walk penalties too.
> (Think of SVN's svn-test-work dirs.) Doable, but would need some
> thought, I think.
I am a contributor to SCPlugin (a MacOS tool like TSVN). The design
for badging files (adding SVN status marks) currently is one area we
have to be very careful about system load, especially for non-system
files (or remotely mounted files). Since we cannot require the user
to describe a WC to us (we have to discover it to be transparent), I
am deeply concerned about the impact this might have.
Currently, we are stateless in the badging process. When an icon is
needed, we compute any badging needed for it. Currently, that means
we call svn library calls to the WC status. If that required a tree
walk up to root, especially for files that are NFS (or SMB) mounted,
that sounds disasterous.
Caching a tree-walk in our code instead of relying on SVN to know the
answer would be possible, but I am not sure we have all the hooks to
know when the cached tree-walk to root is no longer valid. I think
we would need a full filesystem change monitor in our code (which we
have, to date, avoided needing).
Please keep this approach as only an option, so engines like SCPlugin
and TSVN do not have to use them if they affect performance like I
think they might.
Thanks,
Charlie
Received on Tue Feb 6 22:18:26 2007