This page is primarily intended for developers of Mercurial.
This is a speculative project and does not represent any firm decisions on future behavior.
There are certain scalability issues if hg server has many bookmarks. And usually user is only interested in small number of bookmarks. This project will solve these scalability issues by downloading only bookmarks in which user is "interested". By default user may be interested in only one bookmark, for example "master" (it will be configurable). Then if user does "hg pull -B remotebook" or "hg update remotebook" then it's considered that user has shown interest in remotebook and remotebook will be pulled next time.
This project will allow server repos to grow to an arbitrary number of bookmarks without affecting clients performance which in turn will allow to have many scratch branches (for example, one scratch branch per local commit or per code review).
Seems that remotenames extension is a good place for this project.
- Figure out how 'hg pull -B foo' works and use an extension to make 'hg pull' only pull bookmarks that are already in the remote bookmarks list.
Figure out how to intercept hash and bookmark lookups so we can look at the server if needed. Ex: changectx.init is where the normal hash-or-rev-or-bookmark-or-name resolution happens. We might want to implement this as another provider of remotenames that knows how to look remotely. Or perhaps we **build it directly into remotenames** and make this functionality part of that extension.
- Add new wireprotocol for listing only specific remote bookmarks from the server (but existing pushkeys.py::listkeys may be enough in the beginning).
- Make hg checkout pull the remote bookmark when we see the user trying to check it out
- Add new wireprotocol for listing remote bookmarks from the server by pattern. This protocol might be appropriate for upstream and should probably be part of the pushkeys infra.
- Add new command line interface for listing bookmarks by pattern. This is important since our remote bookmark list is only going to grow, and we need a UI that can scale in addition to a pull behavior that scales.