воскресенье, 8 августа 2010 г.
To solve this problem, I implemented a common interface for working with both smart and dumb protocols, called RepoIO. RepoIO makes it easy to add new protocols for Darcs in the future, as well as provides a convenient high-level API for Darcs library users.
The disadvantage of this approach is the need for re-implementing of the download code (for example, at the moment RepoIO does not support HTTP pipelining). However, the current code for download needs refactoring anyway, and getting a clean API with a fresh realization in my opinion justifies the rewriting of some pieces of code.
At current moment changes to the pull command to work with RepoIO have been already made, and soon the first results of smart server's work will be seen. Next week I will finish the implementation of RepoIO for the dumb and smart protocols, as well as the implementation of the server part for CGI and local (to work via SSH). Together these changes will make a working realisation of smart server that is able to serve get and pull commands. Next Sunday I'll make my final report about the completed work.
воскресенье, 1 августа 2010 г.
Last week I spent improving and debugging the code of repository packs. For those unfamiliar with this feature: repository packs are two tarballs, basic.tar.gz and patches.tar.gz, containing the copy of repository contents. They are used for faster getting a Darcs repository over the networks, and will be created by 'darcs optimize --http' command, when it will be enabled.
The main changes are:
- while getting a repository via packs, the files hardlink to a darcs global cache,
- small tuning of packs format, to support the parallel get using cache,
- further development and debugging of code for parallel get,
- optimization of packing of inventories.
пятница, 25 июня 2010 г.
- Implement an optimization for getting repository over HTTP. This is done by creating a snapshot of current repository state.
- Create a smart server for darcs, which is able to determine the patches needed by client and send them with response. This will be the most effective way to get/pull a repository, since it reduces the number of roundtrips to minimum.
Changes so farI glad to report that the most work on HTTP optimization is complete and patches are on their way to the Darcs repository. Some notes on implementation:
- getting an optimized repository results in almost the same copy as for unoptimized one. While inventory files may be split in different ways, semantically resulting repositories remain identical.
- there is still a couple of issues with special cases, like working with cache and handling interrupts; I will hopefully resolve them in nearest time.