A Different Mental Model

It's become clear to me, mainly through some suggestions by a few astute users at Intel, that current Vesta users have a mental model of merging which differs from the users of most (possibly all) other systems. Specifically, they think about the merging of different changes as something which happens at build time. With most other version control systems, merging is something done purely on source files decidedly before a build begins. Only once the user has completed the merge operation can a build start.

I find this interesting because I didn't expect it at all and it seems to have naturally grown out of the way Vesta works today. It seems as though it may be worth trying to preserve the experience which led to this mental model with future merging support in Vesta. Then again, that might break the Vesta model in other undesirable ways. In any case, I think it's worth exploring the idea further, which is the point of this page.

How Build-Time Merging Happens Now

(Because I intend this page for both Vesta users and non-Vesta users, I'm going to explain some of the basics of Vesta here.)

One of the ways parallel development works in Vesta today is by splitting sources up into multiple packages. Packages are versioned independently. Using multiple packages reduces contention without the need to create branches or non-exclusive checkouts (aka "scribbles" or possibly "micro-branches").

The sources from multiple packages are then gathered together with imports in the language used for writing build instructions. This creates a specific build configuration. Consider for example this model:

If we examine its imports, we find that it refers to:

This creates a specific configuration of versions of each of these different packages.

Often builds are set up with some base configuration and a set of version overrides which change the version of specific sources which get used during the build. For example, in vesta/release/12.pre13/7, the base configuration is vesta_umb/12 but the overrides change the versions being used:

When a user configures a build by setting overrides, they are, in some sense, merging the changes made in the different overrides. This is of course a clean merge by definition, because all the changes are made to separate files in separate packages. However, the combined build configuration is clearly the result of merging the different changes together.

In project with multiple developers, users do often refer to the work of others with overrides. In this way their builds merge changes made by multiple users in parallel.