Next plans on radixlink and hash-preserving obsstore

[Augie Fackler]

> On Jul 10, 2017, at 15:09, Sean Farley <sean at farley.io> wrote:
> 
>>> My fear (and therefore warning) here is that we'll spend too much time
>>> discussing this while not shipping evolve. Jun can, of course, work on
>>> whatever pleases him the most. That's cool. But we (mercurial) really
>>> need to focus on getting the basics done first (and, implied, into
>>> core).
>>> 
>>> If I'm the only that thinks this, then alas.
>> 
>> I very much want stuff of this nature to land this year, preferably in
>> the 4.4 cycle. Part of what's been a blocker for core is getting the
>> UX worked out, and it's my sense that Facebook has got something
>> decent worked out that's worth exploring here. We've definitely had
>> some complaints at Google that nibble around the edges of this, and
>> we've still only got eager advanced users. Thus my sympathy for
>> getting a little more of this sorted in the near term.
> 
> I would like to point out that both Facebook and Google have different
> workflows that the average user that we see. So, a UX from Facebook is
> nice but must be weighed against workflows that don't control the hgrc
> (in case that's not obvious).

I agree the workflows will be a little different, but I don't think it's an obvious thing that what's good for Google/Facebook/Mozilla is inherently bad for the users BitBucket can expect. I'd appreciate a little more optimism here that the controlled experiments Facebook has been able to run (and that Google will soon be able to run) are useful information about what's confusing or not in the larger Mercurial user community. That's been largely true over the last few years, and I hope it's true on the history editing flow as well.

> And as Durham points out, we have different carts here. For example,
> improving named branches is also a priority for us.

Totally granted, with the above caveat.

> 
>> Put another way: I don't think sorting out hash-preservation (or not)
>> will take too long, and I think it's worth exploring since it's going
>> to inform the requirements on the marker data pretty heavily. If we
>> forge ahead without taking this detour, we may irrevocably close the
>> hash preserving door, which might be a shame (but we don't know!)
> 
> It might be a shame ... but wouldn't be the end of the world. We've
> shipped things before that we've changed (e.g. bundle1). Anyways, I've
> said a lot and hopefully have made my point. If hash-preservation is
> important to yall then I guess that what you'll work on. For me, I'll
> stick to branching :-)

Improving named branching etc is definitely a righteous thing, even if I don't ever expect to benefit from it. I look forward to seeing what you've got coming.

AF