[darcs-users] sending notices when a repo changes

Gerhard Siegesmund jerri at jerri.de
Sun Mar 6 10:44:15 UTC 2005


Hello

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

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.

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.

With the return-code-checking above I mean, checking if the hook
returned false and then reacting based on this. One example: With the
post-log-hook you could check if a log-entry has a certain form (e.g.
if you define a styleguide for the log entries.). If you can verify the
form of the log-entry several other things can be done later. E.g. in
the post-apply-hook you can check if a bug with a bugtracking-number
was fixed and then close the bug in the bugtracking-tool and fill in
with the log-message. This is only possible if you can guarantee that
the log-entry has a certain defined style and all the information for
this bugtracking-thing can be found in the log-entry.

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. More things to think about:

- which hook-definitions should be copied with every repository, which
ones are only needed in one repository.
- What about cross-compatibility?
- If you define good pre- and post-hooks the preferences "test" and
"predist" can be removed, or can they?
- Could hooks also be used to sign patches?

- more questions?

I hope, my ideas are not too disturbing. I find darcs to be the most
competitive revision control system at the moment. It's simplicity and
elegance are nowhere to be found in the free rcs-systems. Only a little
is missing to be perfect.

-- 
cu
  --== Jerri ==--
Homepage: http://www.jerri.de/   ICQ: 54160208
Public PGP Key: http://www.jerri.de/jerris_public_key.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20050306/aad173ce/attachment.pgp 


More information about the darcs-users mailing list