On Tue, Dec 26, 2006 at 03:35:26PM +0100, Benedikt Schmidt wrote: > David Roundy <[EMAIL PROTECTED]> writes: > > [...] For one thing, it'd be nice to make a WriteableDirectory monad > > for modifying Populations, so that we can use the same apply function > > on Populations as we do on Slurpies, lists of FilePaths and IO. It'd > > require a bit of an extension to the WriteableDirectory monad so that > > we'd not lose the patch name information, but a little function in the > > class (with null default) such as > > > > withNamedPatch :: PatchInfo -> m a -> m a > > withNamedPatch _ f = f > > > > which in the PopulationMonad would cause these changes to be annotated with > > the relevant patch id. If we made this change, it might also come in handy > > for other purposes. For example, when applying in the IO monad, we could > > automatically add to error messages a note indicating which patch failed, > > which would unify our error messages a bit, so that we wouldn't need to > > have quite so many cases where we catch errors in applying a patch just so > > we can add extra information about which patch was being applied. > > > > It could also be helpful if we ever were to develop a "pre-annotated" > > pristine cache. > > I'm working on a filecache (FilePath -> [PatchId] mapping) to speed up > annotate file and changes file. You can lookup if a patch touches > a certain file without traversing all the patches. Then you only have > to parse and apply the subset of patches that change the file for the > annotation info. > > I'm using > StateT [FileMod] m a > applied to Slurpy to find out which files are touched by a certain patch. > I didn't add anything to the WritableDirectory monad and call > > apply_to_slurpy_cache :: Bool -> Patch -> Slurpy -> IO ([FileMod], Slurpy) > > for each patch file instead.
Hmmm. It seems to me like it could be done more cleanely with a modification to apply and WritableDirectory. But I suspect that your code could relatively easily be refactored in that direction if we thought it advisable, wouldn't you think? Just out of curiosity, what is the slurpy needed for? Is it just to do the two things at once, or do you actually need it for updating the cache? > This info is stored in _darcs/filecache/<sha1 of filename> as > > Touch <patchid> > RenamedTo <patchid> <new filename> > RenamedFrom <patchid> <old filename> > > (RenamedFrom for backwards reading). Sounds reasonable. > For now, i added a optimize --filecache option to create the filecache and > read the filecache for annotate and changes. I'm using a Map String () for > now that uses the patchid as key and is used for checking if a certain > patch has to be applied. I don't use Population any more for the the single > file case if there is a filecache, but it's still used for annotate > directory. I'd like to see this (once working and not proof-of-concept) done in the Repository module, so that it is automatically kept up-to-date. Then we'd also want a RepoProperty to indicate that we have this cache, and optimize --filecache could update the _darcs/format file so that future changes will keep it in sync. Using the RepoFormat machinery (rather than just checking if the directory exists) will keep older versions of darcs from modifying a repository that has the cache (although they'll be able to read from it fine). > There is some proof of concept code at http://beschmi.de/darcs-filecache/ > and it really seems to make big difference for big repos. I hope to work > some more on it until and at the hackathon. I'm not sure when I'll have time to look at this, but look forward to checking it out! -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
