Re: arch taglines for emacs

[Tom Lord]

    > From: Richard Stallman <address@hidden>

    >     I agree that it's ugly; arch currently treats everything on the line
    >     following `arch-tag:' as part of the tag-- and that includes 
whitespace.

    > Yes, I gathered that.  What I'm suggesting is that this should be changed.

    > I suggest defining a tag-end sequence for arch.  Suppose it is !!.
    > Then the line could look like

    >     /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89!! */

    > This way, arch does not need to know about the specific comment syntax
    > rules of various languages.

    > Tom, what do you think?

That is a specific variation on the general idea we've been kicking
around for what to do.   It's likely we'll do something like that.
The specific proposal doesn't answer the question of changes to spaces
_within_ the tag:

  /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader <address@hidden>!! 
*/

vs.

  /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader<address@hidden>!! */


It would probably also be a good idea to use string-delimiters and
string-quoting for the tag contents so that it can safely contain 
character sequences (e.g. "*/") that might otherwise confuse language 
modes or compilers.

I realize that, from most perspectives, a change of this sort seems
trivial.   In terms of code changes it is trivial.   Two factors make
me want to take my time before making the change:

1) A reasonable number of users already have arch archives in place.
   Those archives contain changesets.  Those changesets contain
   inventory tags.  If the computation that derives the actual tag
   from the comment changes in such a way that it produces a different
   result, then those older changesets will become broken.

   It would be best, I think, to make the change as a strictly
   compatible extension.  For example, tags using `arch-tag' comments
   will continue to work as is, and tags using `arch-id' comments (or
   some new string) will work in a new way that is delimited and not
   so sensative to whitespace.

   (Miles' first idea was to make a change that would be
   probabilistically upward compatible but I think we've agreed
   now it's worth the extra effort to be strictly upward compatible.)


2) There are some other, more complicated features that have been oft
   requested and which I plan to implement.   These features require,
   in part, changes to the same code.   I'd strongly prefer to do
   these all at once.

   Part of the reason to combine these efforts is because the part of
   the code concerned with computing file inventories is among the 
   most critical in arch:

        a) errors in this code can corrupt archives  -- any
           change to this code, even a seemingly trivial change,
           deserves a lot of testing and review before its release.

        b) misfeatures (as you can see) create a
           backwards-compatability constraint.   It's therefore
           best to think through the kinds of changes we
           can think of to make to the tag comments rather than
           just make each change as the idea occurs.

Finally, again, the particular problem that Miles asked to be solved 
has never been reported s a problem in practice.   It came up as an
issue for Emacs because of a desire to keep the tag comments to a 
single line, e.g.:

        /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */

but that would produce the inventory tag:

        i_53bb84c6-dee0-46c6-a275-2db144993d89_*/

which "seems wrong".   (It would work fine -- it just looks odd.) 
If the comment changed to:

        /*arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89*/

that would (undesirably) change the inventory tag:

        i_53bb84c6-dee0-46c6-a275-2db144993d89*/

I doubt that any of this will represent a real problem in practice.
I would tag the Emacs source with any of:


        /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */

        /*arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89*/

        /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 
        */

        /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89
           (do not change this comment)
        */

and, when a new syntax comes along, switch to something like whichever
of these is appropriate:

        /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89" */

        /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89_*/" */

        /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89*/" */

-t