D2096: infinitepush: move the extension to core from fb-hgext

[pulkit (Pulkit Goyal)]

pulkit added a comment.


  In https://phab.mercurial-scm.org/D2096#35158, @indygreg wrote:
  
  > I see the following high-level potential use cases for infinitepush:
  >
  > 1. A hosting/repo management alternative to //forks//
  > 2. A central repository for submitting changesets to a service (e.g. code review, a "try" repo to trigger CI, etc)
  > 3. As a backup mechanism
  
  
  I think infinitepush can serve as a very good base for solving these problems.
  
  > Let's elaborate.
  > 
  > As I wrote under the //Forks aren't the Model You are Looking For// section at https://gregoryszorc.com/blog/2017/12/11/high-level-problems-with-git-and-how-to-fix-them/, using clones / separate repos to manage //forks// really isn't a great model. I think you want something far less heavyweight where derivations from the main repo are //hung off// that main repo somehow. I think you want a repo-like primitive - let's call it a //workspace// - that is attached to the main repo. Conceptually, imagine that every push goes to a central store. But instead of exposing every changeset with a traditional repository, we instead have different //views// of that data. A //view// in Mercurial technical terms would be defined by a set of heads, bookmarks, phases, obsolescence markers, etc. Although the rules for what data is in that set isn't clear: I think it is valid to have a view that is independent of the main repo as well as a view that is additive to the main repo (that would allow your //fork// to automatically //track// changes to the main repo).
  > 
  > I think the Mercurial server should grow the ability to host //workspaces// instead of //forks//. What this looks like and what role infinitepush plays, I'm not sure. But I do know infinitepush dabbles in this space, so we need to consider it.
  
  That sounds like a very great idea. If we introduce user namespace in infinitpush bundlestore, we can have per user store, where bundles of that user are stored. Then we can introduce a new namespace like `remote workspace` which can be used to push to that workspace. For example:
  
    pulkit$ hg push      # should push to my workspace
    pulkit$ hg pull        # should pull from my workspace
    pulkit$ hg pull --workspace indygreg      # should pull form your workspace
    pulkit$ hg push --workspace indygreg    # should raise an error initially
  
  This will make all the pushes default to bundlestore. Since this thing sounds like a big BC, we can have all this as a part of extension.
  
  > Another use case is a central repository to push/upload to in order to trigger events. For example, you may want to have a central server that receives pushes to trigger code review, trigger a test run of CI, run static analysis, etc. This is different than the //workspaces// use case because the data being pushed is more ephemeral and ad-hoc. There is a difference between pushing something to your //workspace// so you can save and share it versus pushing something to a service to trigger an action on it. To me, this use case sounds best served by server functionality that stashes standalone bundles somewhere and provides access to individual revisions on demand.
  
  I think this can be done using a server which stores all the incoming pushes in the bundlestore unless specified otherwise. The current infinitepush extension can handle that well.
  
  > Our third use case is backups. If a changeset is produced, it gets uploaded/saved somewhere. This is actually a hybrid between the above 2 items. It initially looks a lot like the central repository storing bundles that can accessed on demand. But if you think of each client using the backup service as an individual entity, then modeling each client as having a //workspace// starts to make sense as well. What if each client's state were automatically backed up / kept in sync with a dedicated //workspace// on the server?
  
  I deleted the backup commands, once the initial series get in, will add that back with appending 'debug' in front of command names.
  
  > I think we need to decide which of these use cases we're targeting and what is the pathway (if any) for achieving the remaining use cases in the future. I suspect there is potential to integrate remotenames into our vision here. We definitely need to think about how we'd //address// these offshoot stores. Infinitepush currently uses bookmarks. I'm not sure if we want to be forcing people to use bookmarks or if bookmarks are the best way to //route// pushes/pulls to specific areas of the repository.
  > 
  > @pulkit: I know you have been doing a lot of work with remotenames. I'd be very curious about your thoughts on how you'd integrate //workspaces//, infinitepush, and remotenames. You've also looked at this infinitepush code. So I'm curious about your general thoughts on what you think we should include in core and what our plan should be for adding potentially missing features that I've outlined above.
  
  We need to have a well designed way on how we can differentiate between an infinitepush and normal push. I am not fan of current pattern matching of bookmark which is pushed. We need to have a generic way independent of bookmark, remotenames etc. The `--bundle-store` flag looks good candidate for that.
  
  I think the plan should be something like:
  
  - add capability to have a server which forwards every push to bundlestore and does not require any client side extension.
  - define a good way on how to differentiate between a normal push and infinitepush on server without client side extension
  - functionality to mark an outgoing push as infinitepush on the client side -> this is currently done by the extension but there is scope of improvements
  - add a user namespace in the bundlestore
  
  These steps will serve as good base for the workspace ideas.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D2096

To: pulkit, #hg-reviewers
Cc: indygreg, mercurial-devel