Hi Petr, darcs-users, Op dinsdag 27 oktober 2009 19:29 schreef Petr Ročkai: > New submission from Petr Ročkai <[email protected]>:
Applied, thanks! I do have some questions below however, please scroll down to answer them :-) -- Reinier > Sun Oct 25 15:35:07 CET 2009 Petr Rockai <[email protected]> > * Bump the hashed-storage dependency to >= 0.4.1. Nothing to exciting in this patch, just a darcs.cabal change. > Sun Oct 25 15:35:36 CET 2009 Petr Rockai <[email protected]> > * A vastly more efficient implementation of LookForAdds. >unrecordedChanges :: (RepoPatch p) => [DarcsFlag] -> Repository p C(r u t) > -> [SubPath] -> IO (FL Prim C(r y)) >unrecordedChanges opts repo paths = do > (all_current, _) <- readPending repo > Sealed pending <- pendingChanges repo paths > > relevant <- restrictSubpaths repo paths > nonboring <- restrictBoring > > let current = relevant all_current > working <- case (LookForAdds `elem` opts, IgnoreTimes `elem` opts) of > (False, False) -> do > I.updateIndex =<< (relevant <$> readIndex repo) > (False, True) -> do > guide <- expand current > all_working <- readPlainTree "." > return $ relevant $ (restrict guide) all_working >- -- TODO (True, False) could use a more efficient >implementation... >- (True, _) -> do >+ (True, False) -> do >+ plain <- relevant <$> nonboring <$> readPlainTree "." >+ index <- I.updateIndex =<< (relevant <$> readIndex repo) >+ return $ plain `overlay` index >+ (True, True) -> do > all_working <- readPlainTree "." > return $ relevant $ nonboring all_working I see why this is correct, but not why it is faster. Is it that readIndex uses data from the index when the timestamp on the working directory file is no newer than the timestamp of that file in the index? But how would that help? Is reading a file from the index faster than reading it from disk? Or is it only faster in the case that the repository's pristine is hard linked with another reository's pristine, in which case the timestamps in the pristine may be wrong? > ## The related hashed-storage diff follows, for reviewer's convenience. I have to say, embedding monadic effects in a tree data structure looks pretty cool :-). Of course I knew you were doing it, but this is the first time I see the code. Just one little comment: > +-- | Lay one tree over another. The resulting Tree will look like the base > (1st > +-- parameter) Tree, although any items also present in the overlay Tree will > be > +-- taken from the overlay. It is not allowed to overlay a different kind of > an > +-- object, nor it is allowed for the overlay to add new objects to base. > This > +-- means that the overlay Tree should be a subset of the base Tree (although > +-- any extraneous items will be ignored by the implementation). > +overlay :: (Functor m, Monad m) => Tree m -> Tree m -> Tree m > +overlay base over = Tree { items = M.fromList immediate > + , listImmediate = immediate > + , treeHash = NoHash } > + where immediate = [ (n, get n) | (n, _) <- listImmediate base ] > + get n = case (M.lookup n $ items base, M.lookup n $ items over) of > + (Just (File _), Just f@(File _)) -> f > + (Just (SubTree b), Just (SubTree o)) -> SubTree $ > overlay b o > + (Just (Stub b _), Just (SubTree o)) -> Stub (flip > overlay o `fmap` b) NoHash > + (Just (SubTree b), Just (Stub o _)) -> Stub (overlay b > `fmap` o) NoHash > + (Just (Stub b _), Just (Stub o _)) -> Stub (do o' <- o > + b' <- b > + return $ > overlay b' o') NoHash > + (Just x, _) -> x > + (_, _) -> error $ "Unexpected case in overlay at get " > ++ show n ++ "." I suppose you know that you'll never get a Nothing from the lookup because you get n via listImmediate, which apparently always returns valid indexes.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
