Whole tree up to date before committing

[Stephen J. Turnbull]

Tom Widmer writes:
 > Óscar Fuentes wrote:

Requirement:

 > > We need that every developer test its changes before sending them to
 > > trunk

Does this mean each change be tested separately?  Or it that up the
developer?  (Ie, if you have a risky change, rather than have it block
your other work by failing a whole branch, you would *want* to test it
immediately.  But if you have several small fixes, eg, you're cleaning
up error messages and the reason for testing is you might accidentally
delete a quote mark and break the compile, you'd test only once.
Obviously the cases where a policy would actually bite would be in the
middle.)

Reason:

 > > (the builbots would fail way too often otherwise, apart from
 > > making havoc among those who would update their working copies to a
 > > broken state)

So you are predicting (of course, based on your experience) that due
to the nature of the changes, bad semantic interactions among
concurrent changes are going to be rare.  Is that correct?

Requirement:

 > > and we need to enforce this policy by means of exposing a
 > > credible method for supervising it.

Note that this is precisely what Subversion makes very hard to do.

 > > One possible solution is to use one branch per developer on the central
 > > location (where the master branch resides). A developer tests his
 > > changes, merges from `master' and pushes to his personal central
 > > branch. Then, automatically, this branch pushes to `master'.
 > > 
 > >        merge                      push
 > > master -----> joe's local branch ------> joe's central branch
 > >   ^                                               |
 > >   |_______________________________________________|
 > >                          push

I don't understand what the need for separate local and central
personal branches is.  (Do you think developers might edit history of
their local branches to conceal screwups?  Seems unlikely but I
haven't comeup with an alternative reason.)  It might be preferable to
combine the two and have joe's local workspace be a (lightweight)
checkout from his branch on the central server.  Or simply omit the
central branch.

 > > So we know what he tested (or ought to test) and what was not
 > > tested.

Correct.

Tom Widmer writes:

 > You could possibly simplify this. Just have the shared central branch, 
 > and use checkouts and local commits.

AFAICS this is the bound branch workflows that Óscar doesn't like.

 > Then the developer does:
 > 
 > develop change
 > update and deal with conflicts

Why not update first?  If he is updating a local mirror, it should be
a fast-forward and there's only one window for conflicts, *after*
developing the change.  (Ensuring that it *is* a fast-forward may take
some careful definition of the workflow and for changes that you want
to test separately, possibly an additional local branch to work on a
different task concurrently with the test -- as Óscar has described
his own workflow.)

 > test change
 > commit --local // now we know what he tested
 > push // try to get the change to the central server
 > if push failed, then
 >    update // does a merge, since branch is bound

Óscar's requirements imply:

   // maybe resolve conflicts
   // test merge even if no conflicts

It is this stage that Óscar says will be a bottleneck and will
sometimes delay that change for a few iterations (several hours, at
least), and that does seem probable.

 >    commit // commits merge changeset to central server