<div dir="ltr">On Fri, Jul 3, 2015 at 2:19 PM, Gregory Szorc <span dir="ltr"><<a href="mailto:gregory.szorc@gmail.com" target="_blank">gregory.szorc@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># HG changeset patch<br>
# User Gregory Szorc <<a href="mailto:gregory.szorc@gmail.com">gregory.szorc@gmail.com</a>><br>
# Date 1435958308 25200<br>
#      Fri Jul 03 14:18:28 2015 -0700<br>
# Node ID 17d2b4b8eaaf8bab93d75cfded8042e2d82a3bff<br>
# Parent  84518051bc3b851f736872df045d662de548b3c9<br>
hg: support for auto sharing stores when cloning<br></blockquote><div><br><br><div>First, mpm gave verbal approval for this feature in Montreal. However, it was high level approval only and the details were never worked out. This patch probably needs some bikeshedding on:<br></div><br></div><div>* config option names ("share" vs "clone" etc)<br></div><div>* should flags be added to `hg clone`<br></div><div>* should the path to the shared repo be printed<br></div><div>* should we require the "share" extension be enabled<br></div><div>* should bookmarks be shared by default<br><br></div><div>Also, the role of the "share" extension is kinda funky. A lot of the share functionality is built into core. Before bookmark sharing was added, the share extension pretty much just exposed the `hg share` and `hg unshare` commands (see <a href="https://selenic.com/repo/hg/file/5a4d1a6c605f/hgext/share.py">https://selenic.com/repo/hg/file/5a4d1a6c605f/hgext/share.py</a>). I can argue that the bookmark behavior changes should be in core and not the share extension because weird things will happen if the share extension is deactivated.<br><br></div><div>Anyway, Mozilla really wants this feature so our release automation can be made simpler and more efficient. I'm happy to incorporate any requested feedback as long as the ability to auto share from a common root changeset is present in core (we have 1 repo per head/branch and this is a killer feature for reducing the overall cost of clones).<br></div></div></div></div>