Re: [Gnu-arch-users] automatic messages (for archive cycling etc)

[Tom Lord]

    > From: Miles Bader <address@hidden>

    >> update/replay/etc. can be used to merge from other versions.   Won't
    >> this result in people merging the =update file into the wrong trees
    >> and (sometimes) not noticing until it causes annoyance?

    > Presumably if it got merged, it means the person doing the
    > merging failed to notice the message (and so failed to do what
    > the message asked); subsequent uses of the merged-into branch
    > will then show the message, so hopefully this means he or one of
    > his users will see it, and notify him `hey your branch is
    > borked.'  Once he fixes things up, the message will go away.

    [....]

    >> Or on the other hand, should it maybe be an =update directory with
    >> per-fqversion files?   Perhaps an in-tree commit-guard flag?

    > I don't know, that seems excessively complex.  The simple version seems
    > pretty good to me...

It seems to me that if I merge in a version that has one of these
messages, then I want the message it deposits in my tree to be
somewhat persistent.  For example, if I have patch queue manager doing
these merges, I want the message to persist at least until I get
around to redirecting queue manager.  And if I'm merging in from
multiple versions, several of which have messages?  I think I'd rather
just get the N separate messages than conflicts.

In general, there's some things that all versions should more or less
agree on -- such =tagging-method.   But other things, such as
ChangeLogs, where I want per-version (and thus am likely to use things
like "ChangeLog.d" directories).   I thiink messages are in the
per-version category.

Given that: my next question is "Why are messages a separate file?
Why not just a log header?"

As in:

        X-version-message: This version has migrated

and things that print messages can print:


        =========================================
                This version has migrated

        Archive: ...
        Revision: ...
        Summary: ...
        Creator: ...
        Date: ...

        <log body>
        =========================================

(i.e., print a subset of headers plus the message body, 
formatted loudly.)


    >> Do you mean that those commands should print the message but then do
    >> nothing else?  Or do they also do their usual work?   For example, if
    >> a later commit revised the =update message or removed it -- will I
    >> pick those up anyway?

    > My thought was that `appropriate' commands would check-for/print
    > the message at the _end_ of their run, just before exiting, and
    > _after_ doing their normal task.

    > That would make removing the message easy for both the user (by
    > switching to another branch) and for the branch owner (if he
    > made a mistake, by just committing a changeset to remove it).

That makes some sense.

    > As for what's `appropriate', I'm thinking roughly anything using
    > `whats-missing' internally.  So one implementation might be to
    > have the `whats_missing' function set a global flag somewhere,
    > and then the tla _driver_ would check for this flag, and if
    > true, look for a message file and print it.  This would mean
    > that a message usually reflects the state as the user will see
    > it, not some temporary internal state.

I think it's easier to fine-tune and less spaghetti-like just to have:

        arch_spew_version_messages (chatter_fd, archive, version);

and drop those calls at select points in various cmd-*.c files.


-t