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

[Trent W. Buck]

On Tue, Apr 28, 2009 at 09:34:40PM -0400, Eric Kow wrote:
> My recommendation is to amend this patch to only include things we
> are fairly sure about.

OK; I'll leave this in my queue until I have more time to deal with it.

> 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

It's trivial for two repos to have a suboptimal amount of hard linking:

    darcs get <remote repo> R
    darcs get <remote repo> S

R and S aren't linked, AFAIK.  If there's a cache on the same
filesystem, that may change matters.

    darcs optimize --repo R --sibling S --relink

Now they are optimally linked.

    darcs pull --repo R --all
    darcs pull --repo S --all

Now they are suboptimally linked.  The newly-pulled patches are not
linked.

>>> 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?

I don't recall.

>>>> +-- 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

Fair enough :-) I was thinking that an approximation was better than
an undocumented option.