Stephen Lau 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
I think that is how I expected it was setup anyway.
Maybe a better solution would be to expose via the web interface all
the possible hooks where email could be sent (note I'm not suggesting
general hooks just email); and have the web page explain what will
happen for each of them. That would allow different mail addresses
for each hook, say the project alias for the changegroup hook and
the "lead commiter/gatekeeper" for changeset.
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)
I think regardless of this mail problem (Hi world I was one of the
two people that caused the mail storm), this is a very good feature
to have. I naively expected that this was going to be there as a
feature already, but I guess that is my ON centric view of development.
So yes please add that.
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)
Hmn I don't like this one at all, sometimes it is what you want. What
happens when there is only limit+1 changesets this could get anoying
very quickly for some people.
--
Darren J Moffat
_______________________________________________
tools-discuss mailing list
[email protected]
