Next plans on radixlink and hash-preserving obsstore

[Durham Goode]

On 7/10/17 11:40 AM, Sean Farley wrote:
>
> Sean Farley <sean at farley.io> writes:
>
>> Martin von Zweigbergk <martinvonz at google.com> writes:
>>
>>> On Mon, Jul 10, 2017 at 10:26 AM, Siddharth Agarwal <sid at less-broken.com> wrote:
>>>> On 7/9/17 10:16 PM, Sean Farley wrote:
>>>>>
>>>>> Jun Wu <quark at fb.com> writes:
>>>>>
>>>>>> hash-preserving obsstore,
>>>>>
>>>>> I've commented on this before but I will try to be as explicit as
>>>>> possible here.
>>>>>
>>>>> I do not want to think about hash-preserving obsstore right now.
>>>>
>>>>
>>>> I'm speaking from the point of view of someone who uses obsolete markers but
>>>> isn't involved in the day to day design work.
>>>>
>>>> I do want us to think about it, actually.
>>>>
>>>>>
>>>>> I do not want to think about it for the next year even.
>>>>>
>>>>> I want obs-exchange to solved before hash-preserving.
>>>>>
>>>>> I want all the UI/UX of evolve to be solve and in core before we even
>>>>> *contemplate* (the over-engineered) hash-preserving.
>>>>
>>>>
>>>>
>>>> Hash preservation (or not) is necessarily one of the core tenets of any UX
>>>> based around obsolete markers. This isn't about whether it's overengineered
>>>> -- this is about whether it makes sense to users, and whether an "hg undo"
>>>> command brings you back to the same hash or not is one of the more
>>>> fundamental design decisions to make.
>>>>
>>>> It's usually a good practice to first determine what users expect and work
>>>> backwards from there.
>>>
>>> I completely agree. It's not at all clear to me whether hash
>>> preservation is needed, but I definitely have run into many of the
>>> problems with the current evolve workflow.
>>>
>>> Jun's email was very much about implementation, making it seem like it
>>> was already decided that hash preservation is needed, so I understand
>>> why Sean pushed back (obviously, correct me if I misunderstood, Sean).
>>
>> Correct; and apologies again if I came off too harsh. I really want to
>> have a working (even if not "perfect") version of evolve in core soon.
>> People might disagree with me, of course. Perhaps I just need more
>> coffee :-)
>
> A co-worker reminded of the phrase: let's not put the cart before the
> horse. Which I think is what I'm trying to describe.

I think this comes down to differing priorities for different use cases. 
  You guys obviously have important use cases around exchange and how it 
works with pull requests, so you consider that to be the most important 
piece.

We don't have critical use cases around exchange, but do have them 
around simplifying user mental models and shipping hidden nodes in core. 
  Hash preservation is an important aspect of both. Allowing a 
user/service to refer to and use a commit by a hash (regardless of what 
has happened in the past) gives users confidence and simplifies service 
that deal with commits. Allowing hash reuse allows obsolescence to be a 
drop-in replacement for the existing strip/backup-bundles UIs, which I 
think will make it easier to ship enabled-by-default in core.

So while I agree we shouldn't put the cart before the horse, I think 
there are unfortunately different definitions of cart and horse at play 
here.