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

[John Arbash Meinel]

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

Stefan Küng wrote:
> John Arbash Meinel wrote:
>> 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.
> 
> The only thing that is really common between all those version control
> systems are the paths to the files (and not even those, considering that
> you most likely won't have a file versioned with two of those at the
> same time).
> All other status information (or whatever information is cached) is
> completely unrelated between the systems. So you won't gain one single
> byte of memory by packing all that into one single process.
> 
> Stefan
> 

You missed my point entirely.

What you gain is a *shared* cache. So that you can allow up to XX
megabytes of memory in your cache. And if TSVN is very active, it will
be able to use the whole cache. If both TBZR and TSVN are active, then
they will share the cache. If TBZR is not doing anything, then it
doesn't have to reserve any of the space in the cache.

If you didn't have a shared cache, then each process would need to be
more conservative as to how much it can cache, since it doesn't know how
much is being cached by the other processes.

I would actually estimate that you would save very little based on
paths. Just because you are unlikely to have the same path in both SVN
and BZR/HG/etc. If you did, I'm not sure what the programs would do
anyway. (How do you show that the status is committed in SVN, but
modified for BZR?)

It isn't about saving memory, it is about *sharing* memory.

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

iD8DBQFIDPVTJdeBCYSNAAMRAnEfAJ9DhOCxL2VeRsCrJm2SWlw51y+icgCfSh/n
6VHNgVDvKLSBQK0yim/pdXc=
=U8vw
-----END PGP SIGNATURE-----