[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [msysGit] Re: [Tortoisehg-discuss] Bazzar stratgy regarding shell extension

From: John Arbash Meinel <john_at_arbash-meinel.com>
Date: Mon, 21 Apr 2008 20:33:07 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peer Sommerlund wrote:
...

> In Mark Hammond's proposal the python tortoises need to forward a call from
> a C++ client to a Python server. These few lines could probably be recycled
> without too much effort.
>
>
>
> My gut feeling is that the effort required to generalize the VCS specific
> data could be better used elsewhere.
>
> The VCS specific data would of course vary from tortoise to tortoise, but it
> is not impossible to parametrize this. It could be done with a structure
> similar to, but much simpler than, ADO.NET
> DataSet<http://en.wikipedia.org/wiki/ADO.NET#DataSets>.
> However, it would add complexity.
>
> As I understand the TSVN TortoiseCache, it contains a crawler and a cache.
> If the cache was storing parametrized data, it would be generic. For
> multiple-tortoise users the number of cache processes would be 1 instead of
> N, but the memory and cpu usage would be the same: For each repository the
> cache would store the data needed by that particular VCS.
>

Not necessarily. I assume the caching process could have some amount of
information about how large the cache is allowed to grow. And by sharing
the cache between processes, it would could properly distribute the
cached information based on the more active clients.

While it might be hard to give sizes for parameterized data, just having
a number of nodes cache would still provide say 80% of the
functionality, and allow a nice way to keep memory consumption reasonable.

For example, if you were running TSVN, THG, and TBZR and you have 1GB
installed, you would have to cap all processes at say 250MB to make sure
they never consume 750MB all together. (Numbers are arbitrary.) However,
if you have a single caching process, it could use 500=>750MB. And if
you were only accessing SVN directories, then the "TSVN" portion could
use all 750MB. Which would provide a better overall experience.

> The number of users would be higher (since the code would be shared), thus
> the number of bugs found should be higher. This mostly benefits the smaller
> tortoises: Say TSVN and THG developed this code. TSVN 1.4.8 has been
> downloaded 700,000 times from sourceforge, where THG 0.3 was downloaded only
> 7,000 times.
>
>
> Regards,
> Peer
>

Certainly TSVN has the larger share of users, and the smaller clients
benefit more from using shared code. I don't see why using key,value
pairs would be considered a large overhead over the existing caching
system. I suppose if you had a fixed table in memory, you don't need to
track the "keys", which would save a bit of space. If you had a slightly
smarter cache, though, you would only need to save the keys 1 time, so
the overhead would be quite low.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDOvzJdeBCYSNAAMRAkeUAKCMl6QPTwWrtZCG+Jy5H70bVuQCYACfeyXS
YGPIxEGSeQfCkiWnFCpNv0g=
=S3EB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-04-22 08:05:30 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.