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

[Miles Bader]

On Sun, Feb 01, 2004 at 08:51:29AM -0800, Tom Lord wrote:
> Yup.  It seems nice.   But....
>
> 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.

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

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.

> What about commit?   Should it require an extra option to commit if
> there is an =update file in place?

I don't think so, I don't think it helps all that much.

> Is the automation (building functionality into tla for this) really an
> improvement over just a convention of creating a file named
> "HEY.ATTENTION.README"?

I think so, yes

My experience being that people don't notice things unless you beat them over
the head quite liberally -- and that as they _expect_ updates to add new
files etc., they'll often just automatically ignore them, even if
provocatively named.

Also note that the message will be printed _every time_ the user uses `tla
update/replay', until the tree is changed (presumably by switching branches)
to remove it, which makes it forgiving of a distracted user.

In the case of a message file, of course, it's up to the writer to make sure
it's noticable; I'm thinking:

   +--------------------------------------------------------------+
   |                                                              |
   |    HEY YOU BOZO, THIS BRANCH IS NOW OUT OF DATE!!!!!!        |
   |                                                              |
   |    THE CURRENT BRANCH IS NOW:   address@hidden/blahblah    |
   |                                                              |
   |    To switch, try doing:  tla ...                            |
   |                                                              |
   +--------------------------------------------------------------+

The less anti-social among us can omit the `BOZO'.

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

-Miles
--
97% of everything is grunge