This is an archive of the discontinued Mercurial Phabricator instance.

Differential D1756

remotenames: introduce class to encapsulate remotenames info in an extension
ClosedPublic

Authored by pulkit on Dec 25 2017, 3:50 PM.

Download Raw Diff

Details

Reviewers

durin42

Group Reviewers

hg-reviewers

Commits

rHGcabe8ef5c71e: remotenames: introduce class to encapsulate remotenames info in an extension

Summary

This patch adds a new extension remotenames in which features from hgremotenames
extension (https://bb/seanfarley/hgremotenames) will be added incrementally.
This patch introduces a basic class to encapsulate the remotenames information.

Diff Detail

Repository

rHG Mercurial

Lint

Automatic diff as part of commit; lint not applicable.

Unit

Automatic diff as part of commit; unit tests not applicable.

Event Timeline

pulkit created this revision.Dec 25 2017, 3:50 PM

Herald added a reviewer: hg-reviewers. · View Herald TranscriptDec 25 2017, 3:50 PM

Herald added a subscriber: mercurial-devel. · View Herald Transcript

pulkit added a child revision: D1757: remotenames: introduce a class to lazily resolve remotnames.Dec 25 2017, 3:50 PM

As per previous discussions, the storage part can only go to core directly (https://phab.mercurial-scm.org/D1358#22905). I am not sure about how out of core extension and in-core extension will interact. Also shall I change this extension name to prevent conflict with the out of core one?

In D1756#29970, @pulkit wrote:

As per previous discussions, the storage part can only go to core directly (https://phab.mercurial-scm.org/D1358#22905). I am not sure about how out of core extension and in-core extension will interact. Also shall I change this extension name to prevent conflict with the out of core one?

My 2¢: don't worry about the interactions. The existing remotenames is not published on pypi, so it's very unlikely people have it installed and active as just remotenames= in their extensions block.

No idea if others agree though.

In D1756#31162, @durin42 wrote:

In D1756#29970, @pulkit wrote:

As per previous discussions, the storage part can only go to core directly (https://phab.mercurial-scm.org/D1358#22905). I am not sure about how out of core extension and in-core extension will interact. Also shall I change this extension name to prevent conflict with the out of core one?

My 2¢: don't worry about the interactions. The existing remotenames is not published on pypi, so it's very unlikely people have it installed and active as just remotenames= in their extensions block.
No idea if others agree though.

In that case, I am happy to get this patches reviewed as they are.

durin42 accepted this revision.Jan 18 2018, 3:03 PM

This revision is now accepted and ready to land.Jan 18 2018, 3:03 PM

pulkit updated this revision to Diff 5145.Feb 2 2018, 2:47 AM

Closed by commit rHGcabe8ef5c71e: remotenames: introduce class to encapsulate remotenames info in an extension (authored by pulkit). · Explain WhyFeb 12 2018, 4:33 PM

This revision was automatically updated to reflect the committed changes.

martinvonz added a subscriber: martinvonz.Feb 14 2018, 2:05 AM

martinvonz added inline comments.

hgext/remotenames.py
23	Why does this extend dict? Do we expect callers to update bookmarks by doing something like the following? If not, and the extending of dict is just for the convenience of writing the loop in loadnames() below, we should do it differently and not expose the dict-ness to users. For example, this class could have a dict instead of being a dict. remotenames = ... remotenames['my-bookmark'] = node

martinvonz (Martin von Zweigbergk) <phabricator@mercurial-scm.org> writes:

martinvonz added inline comments.
INLINE COMMENTS

remotenames.py:23
+
+class remotenames(dict):
+ """

Why does this extend dict? Do we expect callers to update bookmarks by doing something like the following? If not, and the extending of dict is just for the convenience of writing the loop in loadnames() below, we should do it differently and not expose the dict-ness to users. For example, this class could have a dict instead of being a dict.
remotenames = ...
remotenames['my-bookmark'] = node

When I wrote this, updating the bookmark (IIRC) was done through a
dict-like interface. Or perhaps I wanted it to be that way so that's how
I wrote it here.

signature.asc832 BDownload

Revision Contents
Changeset List

			Path	Packages
A	M		hgext/remotenames.py (77 lines)
M			tests/test-help.t (1 line)

Diff	ID	Description	Created	Lint	Unit
Base		Base
Diff 1	4610		Dec 25 2017, 3:50 PM	★	★
Diff 2	5145		Feb 2 2018, 2:47 AM	★	★
Diff 3	5522	rHGcabe8ef5c71ece01dccde76aca7901987cb024d6	Dec 22 2017, 1:49 PM	★	★

Status	Author	Revision
Closed	pulkit	D2002 remotenames: add three new revsets related to remotenames
Closed	pulkit	D1759 remotenames: introduce new template keywords for remotenames
Closed	pulkit	D1758 remotenames: add new namespaces for remotebookmarks and remotebranches
Closed	pulkit	D1757 remotenames: introduce a class to lazily resolve remotnames
Closed	pulkit	D1756 remotenames: introduce class to encapsulate remotenames info in an extension
Closed	pulkit	D1755 logexchange: introduce helper function to get remote path name

Diff 5522

hgext/remotenames.py

This file was added.

				# remotenames.py - extension to display remotenames
				#
				# Copyright 2017 Augie Fackler <raf@durin42.com>
				# Copyright 2017 Sean Farley <sean@farley.io>
				#
				# This software may be used and distributed according to the terms of the
				# GNU General Public License version 2 or any later version.

				""" showing remotebookmarks and remotebranches in UI """

				from __future__ import absolute_import

				from mercurial import (
				logexchange,
				)

				# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
				# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
				# be specifying the version(s) of Mercurial they are tested with, or
				# leave the attribute unspecified.
				testedwith = 'ships-with-hg-core'

				class remotenames(dict):
				martinvonzUnsubmitted Not Done Why does this extend dict? Do we expect callers to update bookmarks by doing something like the following? If not, and the extending of dict is just for the convenience of writing the loop in loadnames() below, we should do it differently and not expose the dict-ness to users. For example, this class could have a dict instead of being a dict. remotenames = ... remotenames['my-bookmark'] = node martinvonz: Why does this extend dict? Do we expect callers to update bookmarks by doing something like the…
				"""
				This class encapsulates all the remotenames state. It also contains
				methods to access that state in convenient ways.
				"""

				def __init__(self, repo, *args):
				dict.__init__(self, *args)
				self._repo = repo
				self['bookmarks'] = {}
				self['branches'] = {}
				self.loadnames()
				self._loadednames = True

				def loadnames(self):
				""" loads the remotenames information from the remotenames file """
				for rtype in ('bookmarks', 'branches'):
				for node, rpath, name in logexchange.readremotenamefile(self._repo,
				rtype):
				rname = rpath + '/' + name
				self[rtype][rname] = [node]

				def clearnames(self):
				""" Clear all remote names state """
				self['bookmarks'] = {}
				self['branches'] = {}
				self._invalidatecache()
				self._loadednames = False

				def _invalidatecache(self):
				self._nodetobmarks = None
				self._nodetobranch = None

				def bmarktonodes(self):
				return self['bookmarks']

				def nodetobmarks(self):
				if not self._nodetobmarks:
				bmarktonodes = self.bmarktonodes()
				self._nodetobmarks = {}
				for name, node in bmarktonodes.iteritems():
				self._nodetobmarks.setdefault(node[0], []).append(name)
				return self._nodetobmarks

				def branchtonodes(self):
				return self['branches']

				def nodetobranch(self):
				if not self._nodetobranch:
				branchtonodes = self.branchtonodes()
				self._nodetobranch = {}
				for name, nodes in branchtonodes.iteritems():
				for node in nodes:
				self._nodetobranch.setdefault(node, []).append(name)
				return self._nodetobranch

tests/test-help.t

	keyword expand keywords in tracked files			keyword expand keywords in tracked files
	largefiles track large binary files			largefiles track large binary files
	mq manage a stack of patches			mq manage a stack of patches
	notify hooks for sending email push notifications			notify hooks for sending email push notifications
	patchbomb command to send changesets as (a series of) patch emails			patchbomb command to send changesets as (a series of) patch emails
	purge command to delete untracked files from the working			purge command to delete untracked files from the working
	directory			directory
	relink recreates hardlinks between repository clones			relink recreates hardlinks between repository clones
				remotenames showing remotebookmarks and remotebranches in UI
	schemes extend schemes with shortcuts to repository swarms			schemes extend schemes with shortcuts to repository swarms
	share share a common history between several working directories			share share a common history between several working directories
	shelve save and restore changes to the working directory			shelve save and restore changes to the working directory
	strip strip changesets and their descendants from history			strip strip changesets and their descendants from history
	transplant command to transplant changesets from another branch			transplant command to transplant changesets from another branch
	win32mbcs allow the use of MBCS paths with problematic encodings			win32mbcs allow the use of MBCS paths with problematic encodings
	zeroconf discover and advertise repositories on the local network			zeroconf discover and advertise repositories on the local network