My recommendation is to amend this patch to only include things we are fairly sure about.
On Mon, Apr 27, 2009 at 14:09:15 +1000, Trent W. Buck wrote: > > > + "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 think darcs can do some hard-linking of the pristine cache in old fashioned, come to think of it (and then be clever about just creating a new file on update instead of accidentally breaking somebody else's pristine) > > 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? 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. Did we invoke the "but people can just use hashed repos" argument? > > > +-- 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? > > > + "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. I think as a matter of policy we should not put things in the user documentation that we make up, FIXME comment or no FIXME comment. It seems like we risk generating misinformation/confusion, especially if we (inevitably) forget about the FIXME > > > +-- | 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. OK -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgp83ksnxTTA1.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
