[PATCH 2 of 3] share: accept optional bookmarks parameter

Angel Ezquerra angel.ezquerra at gmail.com
Tue Dec 2 16:23:38 CST 2014


On Mon, Dec 1, 2014 at 9:57 PM, Ryan McElroy <rm at fb.com> wrote:
> # HG changeset patch
> # User Ryan McElroy <rmcelroy at fb.com>
> # Date 1417078134 28800
> #      Thu Nov 27 00:48:54 2014 -0800
> # Node ID beb7a11c50c34e38adea9d8dd3650d42d16cf0ff
> # Parent  c4f7d3fbe855041951dfccb40b05031def426a2b
> share: accept optional bookmarks parameter
>
> This modifies the share function in the hg module so it takes a boolean
> bookmarks parameter and plumbs this through to the share command added by
> the extension. If this parameter is true, the function will create a
> bookmarks.shared file in the destination repository with contents pointing to
> the source repository with which the destination should share bookmarks.
>
> The actual bookmark sharing functionality will be added in a later patch.

Why do you need to write the source path on the bookmarks.shared file
on the destination repository? Shouldn't it be the same path as the
one stored on the sharedpath file?

> diff --git a/hgext/share.py b/hgext/share.py
> --- a/hgext/share.py
> +++ b/hgext/share.py
> @@ -13,10 +13,12 @@
>  testedwith = 'internal'
>
>  @command('share',
> -    [('U', 'noupdate', None, _('do not create a working copy'))],
> -    _('[-U] SOURCE [DEST]'),
> +    [('U', 'noupdate', None, _('do not create a working copy')),
> +     ('B', 'bookmarks', None, _('share bookmarks with source repository')),
> +    ],
> +    _('[-U] [-B] SOURCE [DEST]'),
>      norepo=True)
> -def share(ui, source, dest=None, noupdate=False):
> +def share(ui, source, dest=None, noupdate=False, bookmarks=False):
>      """create a new shared repository
>
>      Initialize a new repository and working directory that shares its
> @@ -34,7 +36,7 @@
>         the broken clone to reset it to a changeset that still exists.
>      """
>
> -    return hg.share(ui, source, dest, not noupdate)
> +    return hg.share(ui, source, dest, not noupdate, bookmarks)
>
>  @command('unshare', [], '')
>  def unshare(ui, repo):
> diff --git a/mercurial/hg.py b/mercurial/hg.py
> --- a/mercurial/hg.py
> +++ b/mercurial/hg.py
> @@ -158,7 +158,7 @@
>          return ''
>      return os.path.basename(os.path.normpath(path))
>
> -def share(ui, source, dest=None, update=True):
> +def share(ui, source, dest=None, update=True, bookmarks=False):
>      '''create a shared repository'''
>
>      if not islocal(source):
> @@ -225,6 +225,19 @@
>                  continue
>          _update(r, uprev)
>
> +    if bookmarks:
> +        bookpath = srcrepo.wvfs.base
> +        # follow shared repo to source
> +        try:
> +            bookpath = srcrepo.vfs.read('bookmarks.shared')
> +            ui.debug('bookmark path changed to %s' % bookpath)
> +        except IOError, inst:
> +            ui.debug('bookmkar path left as %s' % bookpath)
> +            if inst.errno != errno.ENOENT:
> +                raise

There is a typo on the ui.debug message.

> +        destvfs.write('bookmarks.shared', bookpath)
> +
>  def copystore(ui, srcrepo, destpath):
>      '''copy files from store of srcrepo in destpath


In addition to these comments I'd like to know if you plan to add
additional sharing options (e.g. mq patches). On the last sprint I
told mpm that I would look into doing something similar to this. The
idea is to make it possible to use shared repos to create a sort of
subrepository "cache" (although that is not really the right word).

The idea is to add a new "full share" mode that would create shares
that share everything with their source except the minimum amount of
things that are needed to maintain two separate working directories.
In my implementation these full shares would work by making the
destination repository use a vfs that would access the source
repository in all cases except a few exceptions. This seems quite
different to your approach. I'd like to make sure that what you do
does not clash with what I am trying to do.

I already have most of this implemented, but I have been quite busy
with RL these past few months so I am not ready to share it yet (no
pun intended :-) ). I hope to have some time in the next few weeks
though.

Cheers,

Angel


More information about the Mercurial-devel mailing list