[p4] Guidelines for codelines?

Robert Cowham robert at vizim.com
Tue Nov 25 15:35:59 PST 2008

An excellent discussion and some really useful points.

I agree with Rick M that to my mind resolving conflicts in my workspace
before submitting when working on a shared mainline is conceptually just the
same as merging changes into a branch (before copying back to main). And as
he says I find it more risky because the only copy of my changes before I
attempt to resolve against head is the workspace copy, and I might make a
mistake and mess up the resolve while overwriting my changes. Merging into a
branch and getting it wrong can be fixed by reverting and reintegrating

An interesting case I came across was a company doing agile development and
working against a single mainline. They were doing TDD and made sure that
builds/tests were fine before checking in. So the code in their workspace
was the previous stable mainline, let us say at configuration X, plus their
immediate change and its supporting tests, which we can call A, usually up
to a small number of hours of work in a pair. X is valid, so is X + A
(because it builds and tests work). So they check it in. Most of the time
life was good.

Sometimes they had to resolve a conflict. As previously they start with X,
made changes A, and meanwhile someone else checked in changes B. A and B are
not 100% compatible and require a merge which results in the latest state
being X + B + A'. Usually this was not a problem, but from time to time the
business would not authorise the release of A and yet wanted everything else
to be released. Using their mainline only model (with release branches),
they could not go back and find A because what had been checked in was A'. A
itself had existed in the workspace but been slightly modified during the
resolve with B. If they had been using Perforce, what I would have suggested
is a tool to do the equivalent of a "shelve" (sparse branch) of A before
resolving conflicts, such that at least A was safely tucked away and
indentifiable unambiguously in the future should it ever prove necessary to
identify it.

OK, the above is perhaps a touch esoteric, but interesting nevertheless -
caused them pain from time to time.

Many other good points in the thread made which I agree with:

- no single best solution for all situations - instead some good patterns
which have their individual indicators and contra-indicators

- branching strategy is a part of software engineering and shouldn't attempt
to solve the problem in isolation

I think it has been educational for all!


More information about the perforce-user mailing list