gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] automatic messages (for archive cycling etc)
Date: Mon, 2 Feb 2004 10:02:23 -0800 (PST)


    > From: Miles Bader <address@hidden>

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

    [....]

    > I'm not really sure what you mean.  Which log files?  Does tla have to 
search
    > through them to find messages?  Given that (as I've defined it) these
    > messages are _persistant_ -- they get spat out until actively canceled by
    > removing the file -- tla would have to do such searching constantly.

    > The advantage of a single file (or say multiple per-version files in a
    > directory) is that tla doesn't have to work very hard to deal with them.

There's no searching.

My point of view is that there's some commands (such as, say,
`update') which have the property that at the end of the command, we
know which archive(s) and versions(s) we might want messages for.

For example, `tla update $archive/$version' can end with a call:

        arch_spew_version_message (chatter_fd, $archive, $version);

which looks at just the _last_ patch log entry for that version and,
if the header is present, prints the message.


    > Some other apparent points against using log files thus:

    >   * How would such messages be deleted once dealt with?  Would you delete 
the
    >     log file (something which has other consequences in arch, and anyway 
is a
    >     bit taboo)?  Would you add a special `cancel' header to a subsequent 
log
    >     file (adding more complicated mechanism)?

You would cancel it just by committing a new revision to the version
with the message.

The message is only printed when it is for the version you're
operating on, and then only if it is the most recent log message.


    >   * The example you show above suggest a rather fixed format; I rather 
like
    >     the idea of something the user can completely define, and thus use for
    >     occasions that might not be envisioned now (advertising space? :-)

The log message body is pretty free-form.


    >   * I think a single-file/simple-directory-of-files would also be easier 
for
    >     users to understand: the way they would work is really, really, 
obvious.
    >     A special log header, though not rocket-science, looks like it would
    >     entail more rules and mechanism to explain/document.

I don't have any serious objection to use a simple-directory-of-files.


-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]