[darcs-users] sending notices when a repo changes
droundy at abridgegame.org
Sun Mar 6 13:29:56 UTC 2005
On Sun, Mar 06, 2005 at 11:44:15AM +0100, Gerhard Siegesmund wrote:
> > >>What you want is hooks. It would be great.
> > >>I don't know if they are planned or not.
> > >They are indeed planned. It just requires someone taking the time to
> > >actually implement them. They won't even be hard, it just requires adding
> > >a --post-hook flag to all darcs commands, and then you'd set it in your
> > >defaults.
> > >There's even a wishlist bug on the subject...
> > We also need pre-hooks which have the potential to prevent the command
> > from running.
> I wouldn't bind hooks to commands only. I think a better solution would
> be to do event-based hooks. Like e.g.:
> - after a patch was applied
> - before a patch is applied (with return-code-checking)
> - after all patches in a group were applied (e.g. darcs pull -a)
> - before all patches in a group are applied (with return-code-checking)
> - after a log-entry is entered (with return-code-checking)
> - before creating a distribution (with return-code-check?)
> - after creating a distribution
> - etc. etc.
I think your event-based hooks could be implemented via command-based
hooks, and of course the command-based hooks could easily be implemented as
special even-based hooks. However, we already have a reasonably nice
infrastructure for dealing with default options at either a command-based
level or for all commands that accept a given flag--the defaults scheme.
So I think we should make all hooks command-oriented, and we can gradually
add more event-based granularity. We could start with simple --pre-hook
and --post-hook options, which you could think of as the events "darcs is
called" and "darcs finishes".
These are easiest, because a) they can't break darcs (as could any script
that is called after darcs starts work but before it finishes), and b) they
only need to be implemented once, and we've added hooks to all darcs
> I think such event-based hooks could simplify the scripts. The idea
> behind this event-hooks is, that there are several command e.g. which
> apply patches to a repository. So. If you want to do something after
> patches where applied, you would have to add the hook to get, pull,
> push, record, maybe more (hopefully "put" in the future. :)).
It's true that even-based hooks would simplify the hook interface, since
they'd always be called in a particular circumstance. E.g. a
file-or-directory-moved hook would probably have two arguments just as mv
With care, adding support for a given hook to many commands may be as
simple as adding support for that hook's flag (i.e. a two-line change) to
> Each of them work a little bit different (which is why there are all of
> these commands). So in my opinion all of this commands will need
> another hook-script or one hook-script which has to check which command
> called it.
Well, I'd like to (as I said above, but perhaps not clearly) implement
*all* hooks as command-based hooks, so the user has the option of adding to
ALL --log-entry-check-hook grep foo # All log entries must say foo!
record --log-entry-check-hook grep foo # patch logs must contain foo!
tag --log-entry-check-hook grep bar # but tags must contain bar!
> With the event-based hooks you also can define very precise, which
> information will be given to the following script. This is in my
> opinion much better than having to check if certain information were
> available and put somewhere.
Indeed. In my --log-entry-check-hook, I assume that the log entry is
passed on stdin, which greatly simplifies the hooks.
> I think the idea of hooks are a great idea. But they shouldn't be
> implemented too fast. I think a lot of thinking is needed to get them
> right and so to be really helpful.
Agreed... which is part of why they haven't yet been implemented.
> More things to think about:
> - which hook-definitions should be copied with every repository, which
> ones are only needed in one repository.
I'd say all the "real" hooks should be specified on a per-repository
> - What about cross-compatibility?
I think if we take my answser to the previous question, this is a
> - If you define good pre- and post-hooks the preferences "test" and
> "predist" can be removed, or can they?
No, "test" and "predist" must be run in scratch copies of the repository
so pre- and post- hooks wouldn't be enough to make these redundant. One
could add specific "test" and "predist" event hooks, but at this stage
you're just renaming the existing preferences.
On the other hand, having things behave in a uniform manner might be a good
thing. Might it be a good idea to introduce a setprefs defaults, which
defines a version-controlled file that will hold a "default"
_darcs/prefs/defaults? I'm afraid it would mean adding unnecesary
> - Could hooks also be used to sign patches?
I don't think so, at least not usefully. Signatures really need to be made
on inventories, not patches, and signing inventories won't help until the
inventory contains hashes of the patch contents.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20050306/0da8de27/attachment.pgp
More information about the darcs-users