No, but these things generally happen when people have a lot of free
time, or are being funded to do so :)
On 3/19/07, Charles Woloszynski <charles.woloszynski@innocon.com> wrote:
> I am curious, did the thoughts about a centralized repository have a chance
> to turn into any proposals or code?
>
>
>
>
> On Feb 4, 2007, at 1:11 PM, Charles Woloszynski wrote:
>
> 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
>
>
>
>
>
>
> Charles Woloszynski
> Innovative Concepts, Inc.
> Sr. Director, Advanced Networking Systems
>
> charles.woloszynski@innocon.com
> (703) 893-2007 x506
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 14:45:51 2007