Next plans on radixlink and hash-preserving obsstore

[Sean Farley]

Siddharth Agarwal <sid at less-broken.com> writes:

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

Sure, it's something to keep in mind; and I realize that this is
open-source so herding cats and all that.

What I want to warn against is having this block other work (I'll
elaborate below).

>> 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've said this some time before to Jun so apologies if my previous
email came off too harsh; it's more meant as a siren warning).

I sort of agree here. 'hg undo' is a neat feature and a nice-to-have.
But I don't think it's in the top ten list of things to do to get evolve
shipped. Which is my siren warning (yes, I used that phrase above; not
enough coffee to think of a new phrase).

Should it be something to keep in mind so that we don't paint ourselves
into a corner? Sure, absolutely. Do we need 'hg undo' to ship evolve?
I don't think we do (perhaps this is where we disagree).

From my side, I have product managers breathing down me neck about
evolve on bitbucket (specifically, evolve in core hg). It's been far,
far too long in beta (yes, I know; Reasons™). This isn't a criticism of
things past (hindsight is 20/20, of course). This is just a warning of:
if we wait any longer, we might miss the boat.

I can promise that the majority of our (bitbucket) use-case is: branch,
pull request, merge. Even in git (with the reflog), we find that
hash-preservation is not a necessity for working. It's nice to get back
to a previous hash, sure. But we're talking about >90% of users not
needing it.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170710/4934be95/attachment.sig>