On 21/04/2008, John Arbash Meinel <john_at_arbash-meinel.com> wrote:
> -----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.
> >
>
> 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
I'm not getting this at all. You want a single cache process to load
the SVN libraries, the Mercurial libraries, the CVS ... ok, forget
that ... and the Bazaar libraries so that it can store the working
copy information for all these unrelated formats. The cache process is
difficult enough as it is - why would we want to make it even harder?
And almost impossible to test, unless you have all the clients loaded
concurrently, which I certainly don't. Who is going to benefit from
this approach?
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
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:13:41 CEST