one ensemble, multiple codebases

[schmonz]

mob handles a temporary branch in a particular repo. That suffices when all the code being worked on is in that repo. What about when it’s not? Say, for a simple case, when we’re making coordinated changes to a REST endpoint and its consumer. How do?

For everyone to pass around every potentially involved repo on every handoff without effort, my best idea so far is to use myrepos with this .mrconfig:

[DEFAULT]
git_mob = mob "$@"

Then we can say mr mob start 10 or mr mob next and it'll run on all repos in rapid succession. When done, mr mob done followed by mr status to see which repos actually need us to compose a commit message.

This solution depends on an external Unix-specific tool. Could mob be enhanced to optionally operate on multiple repos?

[hollesse]

Is that really needed? In my project we have around 50 different repositories. We sometimes need to change code on multiple services, but we always work an one service first and then go to the other service. Does that differ from your approach?

[schmonz]

Perhaps (very possibly) I'm overthinking. The bigger problem I'm holding in mind is a combination of this one and #360, wanting to avoid handoff friction and/or loss of work when multiple simultaneous sessions are operating in multiple repos. Also I want very much to avoid having to remember correctly which repos we may have touched along the way, but rather shoveling along all our WIP (wherever it may be) on each rotation.

[gregorriegler]

when we’re making coordinated changes to a REST endpoint and its consumer. How do?

Consumer Driven Contracts and Parallel Change come to mind. That keeps em independently deployable. Or if you don't want that you could join those repos. Crossrepo handling is not trivial. mob is very simple and doesn't have any session state. It relies entirely on what git knows.

[simonharrer]

We were thinking of allowing hooks at specific points during the mob commands. With the hooks in place, you could build something like this.

[schmonz]

Consumer Driven Contracts and Parallel Change come to mind

Yes, those are good options for the particular example two-repo scenario I gave. In principle they're always good options to have or to work towards :-)

mob is very simple and doesn't have any session state. It relies entirely on what git knows.

I don't want this to change, and my intuition says it wouldn't have to.

[NVolcz]

I am interested in having this future. Right now I default to only use timer.mob.sh or similar service when working across multiple repos.

mob is very simple and doesn't have any session state. It relies entirely on what git knows.

How does mob store timer state today? Doesn't seem to be stored in git.

[gregorriegler]

I am interested in having this future. Right now I default to only use timer.mob.sh or similar service when working across multiple repos.

mob is very simple and doesn't have any session state. It relies entirely on what git knows.

How does mob store timer state today? Doesn't seem to be stored in git.

You mean this: https://timer.mob.sh/ ?
It sends requests to the server. See the code here: https://github.com/remotemobprogramming/mob/blob/main/timer.go

[NVolcz]

Thanks for the link to the code. I through the timer state were stored somewhere on the file system but it seems to be only stored on the web and handled as a background process.