5.1 The update/commit Style of Cooperation

In earlier chapters, you learned how to add a project to an archive,
store the initial sources, store changes made to those sources, and
retrieve revisions from the archive.

This chapter will begin to explore how multiple programmers can share
an archive, with each of them making changes to a particular project.

You should take note at the outset that there are really many subtle
variations on how programmers can share archives and otherwise
cooperate on a given project. We're starting here with one of the
very simplest techniques. In this example, we will see how to
use a single, central archive shared among several developers.

5.1.1 Alice and Bob Hack main

Let's suppose that Alice and Bob are both working on the hello-world
project and that they are sharing a single archive. In the examples
that follow, we'll play both roles.

Learning Note: If you're following along with the examples, you should
still have a tree in hello-world-Bob that has Bob's changes, but not
Alice's. Try various commands for that directory to explore (missing,
update, changes and so forth).

5.1.6 How it Works – The update Command

A full explanation of how update works is a little beyond the
scope of this chapter. You'll be able understand update in detail
after a few of the later chapters (on changesets and patch logs).

For now, if you are familiar with diff and patch, you can think of
it this way:

When update is run in Alice's tree, it notices that the archive is
up to a patch-2 revision, but that her tree was checked out as a
get of the patch-1 revision. update works in three steps:

First, it uses a command called mkpatch (which is kind of a fancier
variation on diff) to compute a changeset (a fancy patch set)
that describes the changes Alice made to her tree.

Second, it checks out a copy of the patch-2 revision and replaces
Alice's tree with that revision.

Third, update uses dopatch (a fancier patch) to apply the
changeset from the first step to the new tree.

You may be wondering how patch conflicts are handled. The examples
above were carefully crafted to avoid any conflicts. Don't worry –
we'll get to that topic soon enough (see Inexact Patching – How Conflicts are Handled).