Anvil's master branch [continued]

Anvil Q&A
10

It’s nice that you are allowed to do that, but I like to have the published app tracking a branch. That’s how the classic editor works, it’s easy, intuitive and safe.

I may need to use a commit instead of a branch as a workaround to the regression that allows me to edit the published branch, but I would rather have the regression fixed :slight_smile:

I use testing as my testing branch :slight_smile:

This seems to be the only use case where a branch called master (or main) makes sense. This is also an use case that requires some setup and knowledge of git and is not for beginners, so it shouldn’t be the out-of-the-box setup for a new app.

It was guaranteed in the classic editor with the old published branch, it is not the guaranteed with the beta editor. Not only it is possible to edit master, but Anvil keeps checking it out every time you merge from another branch and sets you up for failure.

There are obviously many different use cases, each with its own workflow, but it’s safe to say that there are two main workflows with Anvil:

  • Apps designed to be used as web apps
  • Apps designed to be used as dependencies

In both cases you want to be able to set one (or more) specific version for production while being able to safely edit the app (with one or more developers).

The classic editor does that beautifully with one version and one developer. It’s rigid, but it works out-of-the-box and it’s safe: you edit at the head of the repository and you publish a read-only branch called published. It’s easy, intuitive, safe and out-of-the-box.

The beta editor got rid of published but still requires published for the management of the dependencies, where master is the editing branch. So, if you work on a dependency app, this is neither intuitive nor out-of-the-box.

But it also tells you that master is not the editing branch, because it has buttons to merge to master.

But it also tells you that you do need to edit master because after every merge master is checked out and your first keystroke will edit it. So, if you work on a web app, this also is neither intuitive nor out-of-the-box.

I would go back to the origins and keep what was good on the classic editor and add to it. I wouldn’t try to fix things that were not broken.

A new app in the new editor should come with:

  • One read-only published branch linked to one Published environment
  • One read-and-write development branch linked to one Development environment
  • A Merge to published button to merge the changes on development into published

At this point you get all the features of the classic editor, it works the same way for dependencies and for web apps, it’s safe, it’s intuitive, it’s out-of-the-box, nothing is broken.

Then you can start playing with the app settings and create more branches and change their settings:

  • If you like to do hot fixes, make the published branch read-and-write
  • If you want @owen.campbell’s multi user environment, create a master (or main) branch
  • If you want @jshaffstall’s test environment, create a test branch with its own environment
  • If you have multiple production versions, you can create published-client1, published-client2, etc., each with its own environment
  • If you have more than one read-only branches, then there should be more more than one Merge to xxx buttons
  • You should be able to merge to any branch, even to read-and-write ones, using the context menu

The summary is that:

  • By default an app should have two branches, a read-and-write development and a read-only published
  • If you want anything more than that, you should be able to do it
  • Today the beta editor seems to be trying to give you more than that by starting with an undeletable branch called a mysterious master
  • This default setup doesn’t work for both dependency projects and web app projects and it’s unsafe
3 Likes