[darcs-users] darcs patch: Refactor "darcs optimize" help (and one more).

Eric Kow kowey at darcs.net
Wed Apr 29 01:34:40 UTC 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090428/1429dada/attachment.pgp>


More information about the darcs-users mailing list