Why Versioned Changesets

> OK, but I don't understand why this is two things. You have a merge operation. At night, you do auto-merge. Things that produce conflicts in the auto merge aren't merged and people get to resolve them the next day. They do so by merging and resolving conflicts, so that (unless new conflicts appear) they should get auto-merged the next night.

Yes that is one of the iteration cycles. Another finer-grained one exists but is not often acknowledged: Since developers are not stupid robots they can anticipate most nightly build conflicts and avoid them. One aide in avoiding nightly conflicts is presenting much smaller conflict domains to the developer when he wants to verify his predictions, so that it is dead-cheap to do that chore on the fly rather than in a big-bangish 'got to merge now' focus switch.

I think that if versioned changesets are used an a per-task basis a tool can extract potential conflicts (without even considering which nightly build they were authored on) and present them in a nicely coupled way:

Top level are the latest versions of tasks that have conflicts with the current task, non-conflicting tasks are elided. This toplevel implies a list of people to contact, the developer will know the correspondance between tasks and people for a certain day and wether they can be reached at the moment. By a single glance the developer can see wether doing conflict resolution now is a good idea.

Second level a normal conflict resolution tool is presented on only the conflicts between two tasks. During a single short communication this exact set of conflicts expresses the agenda of communication between the two task implementers.

So versioning changesets will alow me to use the short iteration cycles for conflict resolution purposes (because I introduce dead-cheap mode). This way most nightly build failures are effectively avoided *without developers ever doing a full integration*. (It's an 80/20 thing, I know.)

Additionally the build bots know exactly where to send reports pertaining to conflicts, something that is a rather inexact science in the case of only versioned state, our bots just assume the last publisher can determine whom to forward the problem to (and that she is available!).

So I think I can effectively foist the programmer chores of versioned state composition and error propagation onto the build bots when I have the ability to version changesets. I hope to make merging clearer, faster, suspendable, cheaper and more enjoyable ;-)

Not a small gain.

> The ability to name things that span packages is useful, but I call those streams, not changeset.

I read that as 'package versions'.

I am using the term changeset in a minimalistic way here: a named set of additions, edits and removals. I want to add the ability to version these like we can version packages.

Streams could then be used in their natural way to capture the evolution of both packages and changesets.

There is major overlap of domains between streams, versioned changesets and versioned state. I think this is good because I regard it as an enabler to reifying more version algebra terms as versionable objects.

> and I don't see the need to version them, other than in the trivial sense of having them point at a bunch of versions of the things they involve changes to. That is, I see state-based as entirely adequate for dealing with that.

I am eager to hear suggestions on how to fold above conflict resolution process onto state oriented systems, particularly without the developers being forced to produce package versions (state composition).

> >This is in the context of several pairs working off a baseline build.
> >
> >What you seem to miss is that
> >   a single changeset isn't capable of expressing conflicts but
> >   a set of changesets can express conflicts.
> >
> >
> >
> >Morover in those cases where changeset ancestry branches multiple
> >combinations
> >of changesets are potentially electable into the next build, removing
> >candidate sets with internal conficts can be trivially automated. This
> >together with the practice of reducing conflicts by communication should
> >ensure a succesfull election and hence build most of the nights.
> >
> > From the viewpoint of each team this process reduces multiple merges to a
> >smaller(?) number of conflict resolution sessions where the conflicts are
> >shown by team (changeset) not by package, exactly what is needed for ease
> > of cummunication.
> >
> >Furthermore the internally conflicting versions can be versioned prior to
> >conflict resolution, so a project can be interrupted and versioned at any
> >time without being forced to merge into universion form first.
> >