On Sun, Apr 26, 2009 at 11:49:20PM +0100, Eric Kow wrote: >> Sun Apr 26 22:24:01 EST 2009 Trent W. Buck <[email protected]> >> * Refactor "darcs optimize" help. > > I get the impression that this is both a rewrite and a refactor.
Ah, it's mostly a refactor (reordering and rewriting documentation to be clearer, but say the same thing), but also includes the occasional bit where I've added or removed documentation. For example, this patch now mentions _darcs/inventories bloat and how to GC it with darcs get. I fold both kinds of thing into one patch because it's much easier to do so, and because in my head they're part of the same change. Calling it a "refactor" is not entirely true, but it's more true than false. It's also the naming style I have been using for other similar patches to other Darcs commands. > Refactor "darcs optimize" help. > ------------------------------- > > + "The `darcs optimize --relink' command hard-links patches that the\n" ++ > > + "current repository has in common with its peers. Peers are those\n" ++ > > + "repositories listed in _darcs/prefs/sources, or defined with the\n" ++ > > + "`--sibling' option (which can be used multiple times).\n" ++ > > + "\n" ++ > > + "Darcs uses hard-links automatically, so this command is rarely > > needed.\n" ++ > > + "It is most useful if you used `cp -r' instead of `darcs get' to copy > > a\n" ++ > > + "repository, or if you pulled the same patch from a remote repository\n" > > ++ > > + "into multiple local repositories.\n" ++ > > You're talking about hashed repos here, right? I honestly don't know. I *thought* that hard-linking was applicable to patches in both hashed and old-fashioned-inventory formats. > I also wonder if optimize --relink-pristine even has any effect on > hashed repositories (it's old code). Or would it just be irrelevant > if you've got caches set up anyway. I don't know. > Short of there being a bug, is there any reason for hashed repos to > go out of sync? I'm confused. Are you talking about mtimes getting out of sync, or the breaking of hard links? > And if there isn't maybe we should just remove this flag as well and > push people to use hashed repositories. Just my paring impulse > talkin' just more of that paring instinct talking. IIRC we tried to do this before and Juliusz objected, because he still has a use for it. > > +-- FIXME: someone needs to grovel through the source and determine > > +-- just how optimizeInventory differs from do_reorder. --twb, 2009-04 > > Anybody want to look into this right now? > > I get the feeling we ought to be doing something more organised about > questions about the source code, like having a central wiki page for > them... > > > + "The `darcs optimize --reorder' command is a more comprehensive > > version\n" ++ > > + "of the default optimization. It reorders patches with respect to ALL\n" > > ++ > > + "tags, rather than just the latest tag.\n" > > That's interesting. How do we know this? Well actually, I just made it up based on my anecdotal understanding of how it works. Hence the "FIXME" comment above. > > +-- | Writes out a fresh copy of the inventory that minimizes the > > +-- amount of inventory that need be downloaded when people pull from > > +-- the repository. [Details...] This documentation already existed in the user manual, but I moved it here because I think it's more relevant to internals-discussion. The users now see a discussion of the "black box" effects of "the default optimization" -- it makes many operations use less bandwidth and CPU. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
