regexps.com
In the previous chapter, we began to learn about branching and merging.
We saw how commands like missing
, update
, and replay
can be used
to keep track of and apply changes from multiple branches of a project.
In this chapter, we'll explain a bit about patch logs : the mechanism that is used to keep track of the history of a project tree, including that part of the history that is used for intelligent merging.
You should recall first encountering patch logs in earlier chapters
(l>
The Hackerlab at regexps.com
regexps.com
You can define
meta-projects
which are combinations of individual
projects that are separately tracked by arch
. This allows you to
divide a large project into smaller, more manageable pieces, each of
which can develop independently of the others, and each of which can
be a part of more than one meta-project.
This is accomplished by writing config specs , which define the contents of the meta-project and how they should be arranged in a source tree.
For example, arch
itself is a meta-project. The source tree
contains:
dists/
dists/src/
dists/src/arch/
dists/src/file-utils/
dists/src/ftp-utils/
dists/src/hackerlab/
dists/src/shell-utils/
Each of those directories is the root of a project tree (contains a subdirectory named {arch} ).
The topmost directory, dists
also contains a subdirectory named
configs
. In that subdirectory are the meta-project configuration
files. For example:
dists/
dists/configs/
dists/configs/regexps.com/ # Tom's configuration files
dists/configs/regexps.com/devo.arch
dists/configs/regexps.com/release-template.arch
Here are the contents of devo.arch
:
#
# Check out an arch distribution from the devo branches.
# Latest revisions.
#
./src lord@regexps.com--2002/package-framework--devo
./src/arch lord@regexps.com--2002/arch--devo
./src/file-utils lord@regexps.com--2002/file-utils--devo
./src/ftp-utils lord@regexps.com--2002/ftp-utils--devo
./src/hackerlab lord@regexps.com--2002/hackerlab--devo
./src/shell-utils lord@regexps.com--2002/shell-utils--devo
./src/text-utils lord@regexps.com--2002/text-utils--devo
Each (non-blank, non-comment) line in that file has the format:
LOCATION CONTENTS
which means, to create the meta-project, get the revision indicated by
CONTENTS
and install it at LOCATION
. The CONTENTS
field can be
a branch (meaning, get the latest revision of the latest version on
that branch), a version (meaning get the latest revision in that
version), or a revision name (meaning get that revision, exactly).
To check out an entire arch
tree, I first check out dists
from
devo
, then use build-config
:
% tla get dists--devo dists
[....]
% cd dists
% tla build-config regexps.com/dists.devo
[....]
Once you have a meta-project tree, some other useful commands are:
cat-config : output information about a multi-project config
One use of that command is to generate a list of sub-projects to which some other command can be iteratively applied:
% tla cat-config CFGNAME | awk '{print $1}' | xargs ...
Additionally, the option --snap
can be usefully applied to a
configuration that names subproces by version rather than revision.
It examines the project tree to see what revisions are actually
installed at each of the LOCATIONs
. Then it writes a new config
which specify those REVISIONS
precisely. This is useful, for
example, for recording the specific revisions you are about to turn
into a distribution.
regexps.com
regexps.com
Earlier, you learned how to commit all of the changes within a tree at once (see Checking-in Changes).
You also have read a bit about the importance of making "clean" changesets (see Using commit Well -- The Idea of a Clean Changeset).
This chapter shows you a little trick that you can use in a very specific but common situation.
Let's suppose that you have a large project tree and you're in the middle of making some complicated change. You've modified many files, but there are many others that you haven't touched.
Suddenly, you notice a trivial bug in one of the untouched files.
What you'd really like to do is:
1) Stop and fix the trivial bug.
2) Commit just that trivial bug fix.
3) Get back to work on the complicated changes.
How can you do that?
There's an easy "brute force" solution to the problem.
Simply:
Check out a fresh copy of the latest revision. In other words, create a second project tree with no modifications.
Fix the trivial bug in the new tree and commit. Now you've committed a clean change with just the trivial bug fix.
Use update or replay to Bring Your Original Tree Up to Date. That will add the trivial bug fix back to your tree with the partially completed changes.
That works, but it can be a little awkward. Do you really need to start a second project tree just to fix this trivial bug?
Sometimes the awkwardness is well worth it. For example, your
project might have a policy the before every commit
, you must run
some tests. In that case, yes, you really do need a second tree.
Sometimes the awkwardness is nearly unavoidable. For example, if the
trivial bug fix involves modifying files that you've already heavily
modified, then again, the brute force technique may be the simplest
approach (but also, take a look at tla undo --help
and tla redo
--help
).
But there is a simpler way that sometimes applies:
As it turns out, commit
lets you commit only the changes made to just a few files.
If your quick fix changes file-a.c
and file-b.c
, then after
preparing a log message, you can commit just those files with:
% tla commit -- file-a.c file-b.c
You should note that the files committed this way must not
be new files and that, even if those files have been renamed, the
commit
will record only the changes internal to those files, not the
renames.
In the text above, we speculated about a "brute force" solution to the quick-fix problem that involved checking out a whole new project tree.
Two other command, tla undo
and tla redo
, provide an alternative
"brute force" solution with some advantages. These are described
in a later chapter (see xref :
!!!
)../
regexps.com