On 11/1/06, Stephen Lau <[EMAIL PROTECTED]> wrote:
Currently, our notification mechanism sends a notification for each
incoming changeset. On Mercurial, this means at the changeset level.
For Subversion, this means at the commit level.
We've now had two instances of massive putback overload due to
importing/seeding a Mercurial repository with large amounts of
changesets, resulting in 2000+ putback notifications.
Given that only two people have actually seeded a Mercurial repository -
I expect this will be a recurring problem ;-)
We've got a few ways to go about solving the problem, and there are
different angles of attack: (I'm going to talk about things from the
Mercurial side, since I don't anticipate this problem with Subversion
since you can't "push" massive numbers of changesets since the analogous
seed action is 'svnadmin load'):
(These are not mutually exclusive, and some of these solutions can and
should be combined with others)
1) Move the incoming-changeset hook to the incoming-changegroup hook and
send one notification per changegroup
2) Add a web interface action for "seeding" or loading a repository with
an uploaded bundle; or allowing it to be seeded from an already existing
repository. (For instance any ON projects could instantly seed from
onnv-gate, almost instantaneously using zbringover)
(credit where credit's due: this was Rich Lowe's idea)
3) Add an additional incoming-changegroup hook that detects >10 (or 20,
whatever... this can be subject to debate) incoming changesets and
aborts. Either return failure (bad), or print helpful message telling
them to use the solution we've devised in #2 above (better)
...
any other ideas?
Since the notification email can be easily changed at any time,
why not just point it to some safe email address during the seed
process and reinstate it back when seeding is complete ?
--
Regards,
Cyril
_______________________________________________
tools-discuss mailing list
[email protected]
