Smaller changeset file

Non-SCCS graph format:
  No ^A
  Hex or base 64 format for serial
  Added/Deleted/Same - compress out 0 or remove altogether
     d->same only used in smoosh
Non-SCCS body format:
  file_key {list of serials in descending order}
  Example:
    lm@work.bitmover.com|src/t/t.renumber|19991006215716 8 4 1
    awc@etp2.bitmover.com|src/bkmain.c|20000205002200 5 3
To find out a specific delta, take the largest serial number present
in the serialmap set and look for the corresponding back pointer in
the pointed to file.

Hidden changesets

ChangeSet comments

When the ChangeSet file is selected in citool, put a message in the diffs
window like so:
+---------------------------------------------------------------------+
| Describe the bug or feature you added to the following files:       |
|                                                                     |
| foo.c                                                               |
|   ci comments for foo.c                                             |
|                                                                     |
| bar.c                                                               |
|   ci comments for bar.c                                             |
+---------------------------------------------------------------------+
Victor's point is to make the description and handling of the check be
configurable such that you can ask for an authorization # or bugid
and fail the checkin if they don't have.
citool without ChangeSet
------------------------
When you do a checkin without doing the ChangeSet, then the next time
you run citool, bring up the old deltas and make them read only so
that people can't modify the comments.
Partial ChangeSets
------------------
Provide a way to select a subset of the deltas to add to the ChangeSet.

…​

When we have to merge because of conflicts, then there has to also be a conflict in the ChangeSet file. That should be handled by creating a new changeset at the time the user checks in all the merges.

It would be nice if the ChangeSet file had hints where the hint is a rev number after the key. Then you could look up the rev number and see if the key matched. Might be a perf win, might not.

Need a cset(sccs *s, char *id, char *rev) interface which returns an MDBM database with the {file id, tip id} pairs of all files in the cset.

The cset command needs to be able to read the list on stdin. The sfiles command needs to be able to generate the list of tips on stdout.

Ordering of deltas The latest delta is TOT. If TOT has multiple metadata deltas, it is the latest meta. a Meta delta implies that delta and all earlier deltas until one which is found in prev changeset

Steps involved in creating a changeset

  1. determine the set of files which have changed (or been created) since the last changeset. Include the about-to-be-created ChangeSet delta itself.

  2. Create the new ChangeSet file with the id for the about to be created delta.

  3. Create the delta, using an Init file to get the id right.

Steps involved in creating a patch

  1. Build up a list of file:delta pairs of stuff that needs to be in the changeset.

  2. build up a list of file:delta pairs of stuff in the previous changeset

  3. produce the difference. This may include multiple deltas/file.

The changeset file format needs to be the complete set of root:version pairs of keys which define the state of the tree when the changeset was applied. So a changeset which adds three file:deltas to a tree of 100 files, adds three lines to a 100 line file. To get the state of the tree at any point, you just get that changeset and convert those lines into a set of checkouts on the file & rev. Means that co needs to be able to take a key as a rev.

Allow the use of tags to delimit boundaries of a change set.