[Gnu-arch-users] Re: tagline robustness

[Tom Lord]

    > From: Miles Bader <address@hidden>

Thanks for thinking about this stuff, by the way.

For something like Emacs, I know that there is a request to not
use multi-line tag lines, but perhaps just in the short-term, you
could tag those files with something like:

        /* arch-tag: body-of-tag-with-no-spaces
         */

because such tags will be less prone to the kinds of error you are
worried about, and will convert in an obvious way to the new syntax.

Even less error prone would be:

        /* arch-tag: body-of-tag-with-no-spaces
         * Do not change this comment.
         */

Note that leading and trailing spaces around a tag are _not_ currently
significant.


    > It seems fundamentally necessary to make a change that incompatible in
    > _some_ way:

    > Currently 

    >     /* arch-tag: my-gnarly-tag <address@hidden> */

    > and

    >     /* arch-tag: my-gnarly-tag <address@hidden>  */

    > are different tags, and if you make them the _same_ tag, there exists
    > the (very remote) possibility that somebody will get screwed.

    > The best you can do is to make the probability very, very, low, and I
    > think what I proposed does that.  For practical purposes it's zero.

    > I think it's much more likely that people will get screwed by the
    > problem I'm complaining about, than by this change.

You can't have it both ways.   If you believe people are going to be
screwed by tags that differ only in whitespace (or similar), then you
should also believe that people already _have_ been (mildly) screwed
by that problem and consequently have either or both:

        1) trees in which two tags differ only by "insignificant"
           characters

        2) versions in which the tag of a file has changed (leading to
           a delete/add) because of differences in "insignificant" 
           characters.

An additional problem to worry about is the interaction between
changeset created by versions of tla that have the change you propose
and versions of tla that do not.    It would be best if changesets
formed using the new rule have a form that reliably forces older
versions of tla to choke on them.

Now, to be sure -- I do try to err on the side of caution.  In
general, it's rarely hard to recover from glitches in arch.  There's
certainly nothing to prevent converting old archives if it comes to
that.   But let's avoid getting into such situations if at all
possible: it's the Right Thing for revision control systems.



    > Can you think of a better solution to this problem?  [but don't think
    > too long -- I think it's also important to do something soon, as the
    > number of users appears to be growing quickly.]

Sheesh, calm down.  You're going to cause an accident with that
attitude.

I think that, in general, it will be better to not change the
interpretation of existing tags.   That's the surest way of not
breaking existing changesets.

Next, I'm not too crazy about your proposal to generate tags from
strings containing whitespace the same way they are done now, but
change the comparison.  For one thing, that would make it difficult
for larch or any arch shell tools to reliably `sort -u' a file based
on keys which are inventory tags.

So, this isn't literally what I'm proposing, but it's a straw-man to
start from anyway:

A new tagline syntax might be

        /* arch-tagline: { TYPE } "body of tag" */

or perhaps:

        /* arch-tagline: "body of tag" 
         * { TYPE }
         */

with the rule that whitespace in the quoted "body of tag" is 
dropped (or perhaps converted to a single '_' if you can live with the
tag "foo bar<address@hidden>" being different from "foo bar <address@hidden>").

Given that, a mostly automatic tool can convert tags of the form:

        /* arch-tag: body of tag */

or

        /* arch-tag: body-of-tag-with-no-spaces
         * Do not change this comment.
         */

to 

        /* arch-tagline: "body_of_tag_*/" */

or 
        /* arch-tagline: "body-of-tag-with-no-spaces"
         * Do not change this comment.
         */

Some things to work through before implementing something like
"arch-tagline:":

1) We already an archive format version number which newer clients
   check.   Older clients that pre-date the check of the format 
   version number fail _reasonably_ gracefully -- simply being 
   unable to write to later-format archives.

   Project tree's also have a format version number which is 
   not currently checked.   Perhaps it is time to consider 
   making some changes that will check that.

2) Changesets do _not_ have a format version number.  Perhaps it
   is time to consider adding one.

3) How does this change relate to the other tagging changes 
   described in =TODO?

4) The "{ TYPE }" syntax in the examples above is sort of a 
   place-holder.  There's been a few suggestions that the
   inventory mechanism should be able to keep track of a 
   file type -- e.g., in order to auto-select alternatives
   to GNU diff(1)/patch(1).   Is that worth persuing at the
   same time?

-t