[Gnu-arch-users] adding comments in revc

[Thomas Lord]

Bahadir asks:

    > Is there a way of adding a description tag for each commit?

No but it wouldn't be hard to add one.   In fact, there's two good
ways to do it and having both might be desirable.

(1) If you look in your revc archive, you'll see that each revision
creates a `ticket' file which summarizes the contents of the 
revision.  It has the usual keyword-value header at the top
of the file with a blank line following the header.  It would 
be reasonable to add support to `commit' to let users stick
arbitrary text after that blank line.   It would then make sense
to copy that text into the corresponding position in the
`commit-ticket'.

There are two small catches: character sets and size.  For 
simplicity, comments should be encoded using UTF-8. For lots of
reasons, `ticket'-s should be small.  So it is worth putting in a 
restriction to prevent users from sticking a modest novella there.

(2) Using revc as a library or as a subprocess for a front-end,
allow commit comments to be prefixed to a conventional ChangeLog
file or similar before the commit.  If you have the `ticket' or
`commit-ticket' in hand, it would take two file-fetches to extract
that ChangeLog from an archive (one for the root directory, the 
next for the ChangeLog itself).

Option (1) is nice for the kind of comment that you would want to
travel with announcements about the availability of a new revision.
Such announcements would normally come with a `ticket' or 
`commit-ticket'.

Option (2) is nice for longer comments (e.g., a detailed description
of all the changes).   The fast access you'd have to the ChangeLog
file with option (2) illustrates a larger point:  it makes sense
to make a front end that allows one to mount a revc archive as 
a filesystem of revisions (like Vesta or some of the commercial 
systems).

Should you decide to make either change, please, please, please
try to stick to the minimalism, simplicity, and cleanliness of the
original code.   The code is "librified" from the start precisely
because it shouldn't, like tla did (especially in a certain branch),
become a dumping ground for convenience hacks.  The files in `deps'
are the ones you'll need to adjust for the error handling regime of
an environment in which you want to use it as a library.

  > Secondly, if I've done commit A, commit B and commit C, and these
  > commits are irrelevant of each other, how would I retrieve a 
  > commit C, but undo combinations like, commit A, A and B, etc?

Take a 2-3 month digression to port Arch's mkpatch/dopatch to the
librified style of revc.   Perhaps make use of a level of filesystem
virtualization (vu?) so that they can operate on archived trees
directly.  From there, all of the familiar merging features of 
`tla' are a snap.

`revc' doesn't need to, and so doesn't, enforce the hygiene of
tagging that `tla' does.   It's up to front-ends whether or not
to add that expense to commits -- it certainly doesn't go in the core.
(For a few years we've talked about how inventory logic ought to
be strictly orthogonal and, in revc, it is.)


Matthew is roughly right about the status of revc but, of course,
can't resist pimping for Canonical and slagging me.  Oh well.
*I* still use revc.  I still believe it merits much additional 
development.  That and a buck fifty will buy a house coffee while
stiffing the barista on the tip.

Still, it's free software.  It's only dead if nobody bothers to 
do anything with it.

-t