Aditya wrote: > Patch index improves the speed of changes and annotate commands by > quickly > identifying the patches that modified a given file. This optimization > is especially useful for large repositories.
How large is the expected gain? Can you share some performance numbers, i.e. comparison of commands on e.g. darcs repo with and without index? > The public repository is at: > http://den.darcs.net/Aditya/darcs-patch-index > > Patch index will be automatically created upon get or init. > > If you run changes/annotate/record/.. using patch index darcs on an > existing repository, patch index will be created automatically. > Alternatively, run optimize --patch-index to exclusively create patch > index. > > You can disable patch index using optimize --no-patch-index, and enable > it > back with optimize --patch-index. If you wish to disable patch index > at creation, pass --no-patch-index. A lazy get will implicitly disable > patch index, as you require to have all patches to create a patch index. I cannot see a use case for optimize --no-patch-index, except for measurements or debugging; however, it doesn't hurt to have it, either. > at creation, pass --no-patch-index > I request users to try patch index darcs, and give feedback on potential > ui changes, bugs etc > > One of the concerns I already have is automatic creation of patch index > on > existing repositories. The time it takes to create patch index increases > dramatically based on buffer > cache<http://oss.sgi.com/LDP/LDP/sag/buffer-cache.html>. > Creating a patch index just after get takes 6 sec, whereas it takes 1min > after cleaning the cache(This is for darcs development repo). This > suggests that a user could experience a potentially large delay on > changes/record/.. . I share your concern. Creating the patch index for a whole repo in one go will certainly take a long time for large repositories. So, to overcome this problem, I would propose to create the index incrementally. The idea is that the index caches what the darcs command finds out, letting the index grow over time and use (explicit optimize --patch-index notwithstanding). No long extra delays for get, and the extra time to cache the information into the index would probably be negligable. For darcs init, it makes sense to always start with an index, and update the index on each record or pull. The explicit optimize command has the advantage that I can let darcs do the work in the background, maybe even at night by a cron job when I don't care how long it takes. Cheers Ben _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
