Thoughts on remotenames additions to remotebranches

[Ryan McElroy]

On 1/12/2015 2:11 PM, Augie Fackler wrote:
> On Mon, Jan 12, 2015 at 01:07:38PM -0800, Sean Farley wrote:
>> Ryan McElroy writes:
>>> Sean Farley has done a bunch of legwork over the past few weeks to
>>> put in some generic namespace infra to mercurial. He now has a
>>> 'remotenames' extension (based on remotebranches) that uses this
>>> functionality to implement remote bookmarks functionality; check
>>> it out at https://urldefense.proofpoint.com/v1/url?u=https://smf.io/hgremotenames&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=zxRJZ6melt%2FqLtQ%2Bw2Gaeg%3D%3D%0A&m=m%2F2i6XuCA4s8pIBAXxEis6jCBnIasuxJJoicXGyfLWc%3D%0A&s=248c287965963b02785308c5a4a77811fad3966a1083df62680ec13db84bab3c.
>>>
>>> The ideas here are pretty exciting and I'm super happy Sean is
>>> working in this direction. Below are my high-level thoughts on the
>>> extension. Many thanks to Durham Goode and Pierre-Yves David for
>>> providing feedback to me and letting me bounce ideas off of them.
>> Thanks!
>>
>>> (1) There appears to be some nice functionality in the
>>> remotebranches extension (such as the upstream() revset)
> I've sometimes thought about trying to split upstream() out of
> remotebranches. It'd be nice to seed the discovery process with the
> list of revisions we think the server has somehow...
>
>> , but I
>>> don't think remote branches and remote bookmarks should every
>>> share a namespace (in this case the "remotenames" namespace). I
>>> think combining these ideas makes using each effectively
>>> harder. I'm not against the idea of having both functionalities in
>>> one extension, per se, but having them share a namespace is the
>>> things I'm concerned about here.
>> Yeah, that makes sense. Pretty easy to make this change, I think.
> I agree with this, FWIW. I do think having it in one extension
> probably makes sense, if only to be able to share the underlying
> datastore (see above ideas about seeding the discovery process).
>
>>> (2) When remote bookmarks are enabled, I think it makes sense to
>>> prevent normal bookmark syncing (h/t Durham).
>> I agree with this but have no code written (hint: patches welcomed).
> What does that look like behaviorally? I'm curious.

I'll throw out some design ideas as we go, but the short version is: if 
there's a 'master' bookmark on a remote, and a 'master' locally, a pull 
will update the remote bookmark 'master' but will not touch the local 
bookmark master as it currently does. Same with push.
>>> Corollary: (3) How do we push to a particular remote bookmark from a local bookmark?
> This one, in particular, it'd be good to sort out without reinventing
> the complication of git's remote tracking mechanism.

Agreed -- I like tracking branches but don't think they should be 
necessary to make the system behave in a sane/usable way. I think they 
are secondary and I won't implement them immediately, but I would like 
something like them to allow things like "how many ahead/behind" is this 
bookmark, if the user wants to enable them. But again, not part of the 
first iteration.
>>> Corollary: (4) How do we delete remote bookmarks?
>> Those are good questions that we should discuss.
>>
>>> (5) (Sean has mentioned this as well) we need a way to display all
>>> bookmarks, local and remote (eg hg bookmarks --all flag)
>> Yeah, this is pretty easy, too. I'll fix this soon.
>>
>>> There are a few other small features that Durham thought would be useful as well:
>>> * Allowing certain remote bookmarks to always be visible (eg, master/@/trunk remote bookmarks)
>>> * Prevent local bookmarks from interfering with remote bookmark names (eg, prevent '/' in bookmark names)
> I thought we had at least in passing talked about trying to do this in
> core? Didn't we reach some kind of consensus about what we wanted to
> do to bookmarks behavior back in Munich?

We can start it out in the extension and if it looks good and everyone 
is on board, move it into core after the new version comes out, perhaps 
with a configuration option.

>>> * Use bundle2 to prevent race conditions with listkey after pushes
>> Agreed (patches welcomed!). Another one to add to the list:
>>
>> * improve craziness with divergent (e.g. 'bookmark at 1') behavior
>>
I think preventing the default bookmark behavior would prevent divergent 
bookmark behavior, if I'm understanding things correctly.

It looks like everyone is on board with the basic direction and Sean is 
willing to take patches (yay \o/) so I'll start hacking this up and we 
can discuss as we go.

Regarding discovery, I don't know enough about that mechanism yet but it 
sounds like we could punt on that for now because it's not related 
directly to the core functionality here, but rather an optimization we 
can do afterwards.

Thanks all!

~Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150112/cb6424b2/attachment.html>