|
Size: 1468
Comment:
|
← Revision 4 as of 2016-08-09 15:26:57 ⇥
Size: 2307
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| There are certain scalability issues if hg server has many bookmarks. And usually user is 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". If user does "hg pull -B remotebook" or "hg update remotebook" then it's considered that user has shown interest in remotebook. | 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. |
| Line 10: | Line 10: |
| This project will allow server repo's 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). | 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). |
| Line 12: | Line 12: |
| A good place for this project is remotenames extension. == Detailed description == All kind of stuff can go here, solution description / alternative solution etc |
Seems that [[https://bitbucket.org/seanfarley/hgremotenames|remotenames]] extension is a good place for this project. |
| Line 18: | Line 15: |
| * 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. As mentioned in #3, we may want to build this directly into the remotenames extension. * (./) step * {X} That * {X} need * {X} to * {X} be * {X} performed |
* 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. |
| Line 26: | Line 22: |
| == See Also == * pointer * to * related * page |
Note:
This page is primarily intended for developers of Mercurial.
Selective Pull
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This is a speculative project and does not represent any firm decisions on future behavior.
1. Goal
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.
2. Roadmap
- 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.