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: Sun, 1 Feb 2004 08:51:29 -0800 (PST)

    > From: Miles Bader <address@hidden>

    > Ok, here's a new idea for this sort of `automatic message functionality'
    > that's _very simple_ and I think addresses the concerns I've seen raised
    > about past proposals for implementing such a feature:

    >  1) At the end of an update/replay/whatever command, tla looks in {arch} 
for
    >     a file called {arch}/=update-message, and if found, prints the 
contents
    >     to stdout.

    >  2) That's it

    > The way of using it should be obvious:  You just commit an extra 
changeset to
    > `out of date' branches that contain an =update-message file with an
    > appropriate message; presumably any continuation tags point to the 
_previous_
    > changeset, before the one containing the message (though it's obviously 
not a
    > big deal if they don't -- it's easy enough to commit a changeset to remove
    > the message file).

    > Some advantages to this approach:

    >   * Really, really, simple, and easy to understand
    >   * No extra network overhead for remote archives
    >   * Mirroring does the right thing, and there's no extra overhead for it
    >   * If you change your mind, you can commit another changeset to remove 
the
    >     file, and again mirroring etc. do the right thing
    >   * You can use this when changing versions too (i.e., it's not 
`per-archive'
    >     like previous suggestions I made)

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?

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?

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

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

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

-t






reply via email to

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