[Top][All Lists]
[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 08:17:03 -0800 (PST) |
> 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