[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Every project tree has an associated patch log: a collection of log
entries for each commit
or import
in the history of that patch
tree. When you commit a new revision, the log entry you write is
saved in two places: it is saved in the archive as a plain text file
(for browsing and as a record of complex ancestory relationships), and
in the project tree itself (for browsing and to control history
sensative merging).
Logs are organized by version. The command:
% arx logs |
lists all of the version names for which a project tree has a patch log.
The command:
% arx log-ls [[ARCHIVE/]VERSION-NAME] |
lists all of the patch levels for which a tree has log entries (for
revisions in the indicated version). With the summary
flag:
% arx log-ls --summary [[ARCHIVE/]VERSION-NAME] |
the Summary:
header of each log entry is printed.
To see the complete text of an entry, use:
% arx cat-log [ARCHIVE/]VERSION--PATCH-LEVEL |
When you form a branch, project trees on the branch have (at least) two patch logs: one for the original development path, and one for the branch itself. When you merge changes from one branch to another, so long as both branches have the same project category, the merged tree has patch logs for both branches. ("Project categories" were introduced in The ArX Global Name-space of Projects).)
You can find out if an archive contains patches that haven't yet been applied to your project tree with this command:
% arx whats-missing [[ARCHIVE/]VERSION ...] <list of missing patches> |
That command compares the patch log stored in the archived with the patch log found in the project tree and prints the list of missing patches. There may be missing patches if your tree is not up-to-date with respect to the archive, or if when your tree was created, some patches were skipped.
You can see the Summary:
line of each missing patch with:
% arx whats-missing --summary [[ARCHIVE/]VERSION ...] |
If you want the list to contain fully-qualified patch level names,
use the --full
option.
If you want to know where branch A stands in relation to branch B, one way to find out is with:
% arx get A dir |
% cd dir |
% arx whats-missing B |
(It is possible to obtain the same information without having to get
a revision from branch A, using commands already introduced, plus some
other shell commands. The details are left as an exercise for the
interested reader.)
The command arx changelog
generates a GNU-style
ChangeLog
file from a patch log:
% arx changelog |
or
% arx changelog [ARCHIVE/]VERSION |
The ChangeLog
file generated for ArX
, for example, might begin:
# do not edit -- automatically generated by ArX changelog # # tag: automatic-ChangeLog--lord@regexps.com--ArX-1/ArX--devo--0.5 # 2001-12-17 Tom Lord <lord@regexps.com> Summary: `update' and `replay' output format and bug fixes `update' and `replay' -- structured output and updated argument processing for reasonable defaults. `replay': copy precious files before (not after) appling patches so they are carried along with directory renames in patch sets. `dopatch': don't pipe `arx heading' into `arx body-indent'. modified files: ChangeLog src/ArX/=TODO src/ArX/branching-and-merging/replay.sh src/ArX/branching-and-merging/update.sh src/ArX/patch-sets/dopatch.sh 2001-12-17 Tom Lord <lord@regexps.com> Summary: [...] |
If someone has a full distribution of your work, they can generate a
ChangeLog as needed. You can also include ChangeLogs in tarball
distributions using the --changelog
option for
update-distributions
. That will make a directory ChangeLog.d,
and the ChangeLogs will go in ChangeLog.d/ARCHIVE/REVISION. If
ChangeLog.d already exists, then ArX will not put Changelogs into that
tree.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |