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

[indygreg (Gregory Szorc)]

indygreg added a comment.


  In https://phab.mercurial-scm.org/D2096#35153, @pulkit wrote:
  
  > In https://phab.mercurial-scm.org/D2096#35123, @indygreg wrote:
  >
  > > I can take review of this series since this feature is of extreme interest to Mozilla. I //might// get around to looking at it this weekend. But no promises.
  >
  >
  > Do you have thoughts on which functionality from the following you want in core?
  >
  > - the --bundle-store flag to push command
  > - functionality to pull from bundlestore using hg pull
  > - functionality to pull changesets from bundlestore if a changeset is not found locally on hg update
  > - logic around sql store
  > - interaction with the hoisting functionality of remotenames extension which is also being moved to core
  
  
  I haven't looked at the full code in detail yet. But I think we should take a step back and think about what are the fundamental features/workflows we're trying to accomplish with infinitepush.
  
  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
  
  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.
  
  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.
  
  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 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.
  
  My hunch is that teaching the server to accept incoming pushes and store them in standalone bundles (instead of as part of the main repo store) is a much easier problem to solve than providing //workspaces//. I don't think it requires nearly as many changes and will introduce few - if any - user-facing changes. But the feature isn't as valuable as persisted //workspaces// would be.
  
  @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.

REPOSITORY
  rHG Mercurial

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

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