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
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
signature.asc
Description: OpenPGP digital signature
