[Gnu-arch-users] Re: tagline robustness

[Miles Bader]

On Wed, Aug 20, 2003 at 07:45:26AM -0700, Tom Lord wrote:
> Even less error prone would be:
> 
>       /* arch-tag: body-of-tag-with-no-spaces
>          * Do not change this comment.
>          */

But of course, even more ugly (and I think it's an important attribute of
taglines that they be `unobtrusive', especially for people like me that are
going around asking `Can I add this to _all_ your source files?' :-).

>     > 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

Why?  I think the current number of arch users is fairly small, and dominated
by people who understand arch quite well.  Those are the sort of people that
would know well not to ever screw with taglines, and would likely be able to
deal with any problems that did occur.

However my impression is that more big projects are looking at arch recently,
and that the user-base is likely to change in character pretty drastically
(not to mention the effect of a simple numeric increase in users).

[Throw enough monkeys at the problem and ...]

> 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.

Well that would be the _safest_ way.  As I said, I think the probability for
error is so low that in practice it's not really necessary -- but it's your
call.

[However, my argument does assume the particular method I described, and your
objections about `sort -u'ability &c are valid]

> A new tagline syntax might be
> 
>       /* arch-tagline: { TYPE } "body of tag" */
> 
> or perhaps:
> 
>       /* arch-tagline: "body of tag" 
>          * { TYPE }
>          */

It seems bad to have arch search past the newline, and I'd think that the
{ TYPE } part should be optional (no?).  How about just allowing either
placement, and saying `If { TYPE } follows the tag, it must do so directly.'

I.e.:   /* arch-tagline: { TYPE } "body of tag" */
or:     /* arch-tagline: "body of tag" { TYPE } */

Is " then an illegal character for tags?  That would be simple (no quoting),
but then there are existing tags you can't represent.  Does this new syntax
use the same internal `tag tag' in changesets (I forget what it is for
taglines, but it's `x' for explicit tags)?

What happens if there's a newline before the terminating " ?

[BTW, it's a bit funny -- the `old' format really was a a tag _line_, but
called `arg-tag', and this new format _isn't_ really a line, but is called
`arch-tagline'...]

> 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>").

How about converting (runs of) whitespace to `_' only if occurs between
alpha-numerics, and otherwise dropping it?  That seems pretty safe.

> 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.

It seems that just implementing the above won't actually cause the new
clients to write anything different to the archive, if you're still using the
same source files -- the main problem is if you actually rewrite your source
files to use the new syntax.

So maybe you could have the new tla client barf it sees a changeset
containing a new-format tagline being committed to an old-format archive, and
print a message saying `please run tla-bump-archive-version' before
committing this changeset [+ assorted warnings]'

[I guess a hacky implementation could just set a global variable
`I_saw_a_new_format_tagline' for later checking.]

That way people would have a lot of time to convert, since there's no great
pressure to use the new format, but it's simple for them to convert once they
decide too (and they could do it piece-meal).

>    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.

In what case?

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

Seems reasonable.  Would that impact this change though (I thougt the
changeset contents -- other than the actual source files -- would remain the
same regardless of whether `old' or `new' taglines are used)?

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

Which ones?  I briefly looked at =TODO in tla, and everything in there seems
basically orthogonal.  [There's an indirect reference to somehow making arch's
internal `tag tag' explicitly part of the tag.]

> 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?

Maybe worth keeping in mind, but in general it seems better to avoid making
your problems _too_ big...  E.g., make `pursue' == `think briefly about how
such might be fit into the scheme of things, and make sure there's room to
implement it, but don't actually implement anything.'

Thanks,

-Miles
-- 
Run away!  Run away!