On Sat, Sep 03, 2005 at 05:04:23PM +0200, Daniel Lutz wrote: > An other idea (for improving efficiency in a second step if necessary): > Supposed some locking mechanism is implemented. Then caching could be > introduced (user = e.g. script): > > 1) user requests write lock on the repository > 2a) user requests file content of file A after patch X to stdout > -> generate a cache file (e.g. containing file A after patch X) > 2b) user requests file content of file A after patch Y (after X) to > stdout > -> use cache file > ... > 3) user releases write lock > -> cache files are deleted
Yeah, that would be an neat trick, especially since the lock command would be useful even in the absence of a caching mechanism. Note that I'm still leaning towards a lock command that releases the lock on exit. If you want to familiarize yourself with darcs and haskell, this would be a pretty easy command to implement. The procedure for creating a new command is pretty simple... I was about to outline them here, but instead realized it would be smarter to add this to the wiki, so you can pick up some advice at: http://wiki.darcs.net/index.html/AddACommand You could take any of the commands that create a lock as a starting point, and pretty much just follow the instructions and gut the command (maybe make it just putStr an instruction to hit return to release the lock and then getChar and exit. -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
