464029 - pushlog needs branch-awareness

Status: RESOLVED WONTFIX

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[(not currently active) Ted Mielczarek]

Currently the pushlog is ignorant of named branches, and will just list all pushes from all branches. We should fix it so that it takes a branch parameter so that we can make the buildbot HgPoller poll the default branch only.

Comment 1

[(not currently active) Ted Mielczarek]

This is still a little crappy even after my fixes for bug 464018, because the underlying Query code doesn't actually touch the repo, so it still doesn't know anything about branches.

Comment 2

[(not currently active) Ted Mielczarek]

So I think there are two possible ways to fix this bug:
1) Add a "branch" column to the pushlog db, and provide a migration script to update existing databases to the new schema (would have to trawl the entire repo and add a branch entry for every changeset). The pushlog hook would need to be updated to store the branch for every changeset.
2) Change the query mechanism such that it does a second pass on each query, getting the changeset from the hg repo for each result and checking the branch. This would make every query more expensive, since currently the pushlog ATOM feed doesn't hit the actual repo data.

I think #1 sounds like the best way to go. The pushlog schema is defined here:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hghooks/file/b0bd1940eff8/mozhghooks/pushlog.py#l23
I think we'd probably want the branch column on the 'changesets' table, since you can push multiple changesets on different branches in one single push.

We've done a migration script before (the current pushlog is on pushlog2.db, in fact):
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hghooks/file/b0bd1940eff8/mozhghooks/pushlog.py#l55
The new migration script wouldn't have to be quite as complicated, it could probably just copy pushlog2.db to pushlog3.db, open the new db and run an ALTER TABLE to add the new column, then select * from changesets; and for each changeset in the db, use the Mercurial APIs to get the change context object from the repo, get its branch(), and update the column:
http://mercurial.selenic.com/wiki/MercurialApi#Change_Contexts

It would then be straightforward to change the pushlog-feed code to take an optional branch query parameter and query on it:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/pushlog-feed.py#l210
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/pushlog-feed.py#l44

Comment 3

[Benjamin Smedberg]

There is the possibility that you can push a new head on two branches simultaneously. We should either prevent that in the hook, or add multiple entries (one for each new branch head).

Comment 4

[Chris AtLee [:catlee]]

(In reply to comment #3)
> There is the possibility that you can push a new head on two branches
> simultaneously. We should either prevent that in the hook, or add multiple
> entries (one for each new branch head).

What do you mean?  Can a single changeset be part of multiple branches?

Comment 5

[Justin Wood (:Callek)]

(In reply to comment #4)
> (In reply to comment #3)
> > There is the possibility that you can push a new head on two branches
> > simultaneously. We should either prevent that in the hook, or add multiple
> > entries (one for each new branch head).
> 
> What do you mean?  Can a single changeset be part of multiple branches?

He means that a single push could have two changesets targeting two separate branches.

Comment 6

[Chris AtLee [:catlee]]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > There is the possibility that you can push a new head on two branches
> > > simultaneously. We should either prevent that in the hook, or add multiple
> > > entries (one for each new branch head).
> > 
> > What do you mean?  Can a single changeset be part of multiple branches?
> 
> He means that a single push could have two changesets targeting two separate
> branches.

Ok, that's covered by having the 'branch' column in the changesets table rather than in the pushes table, right?

Comment 7

[(not currently active) Ted Mielczarek]

That would handle it, yes, at the cost of bloating the changesets table in the default case.

Forbidding pushes on multiple branches at once is plausible, although it might cause people some pain. (Also we most certainly have existing pushes like this in the db, so we'd have to split them up or something.)

Comment 8

[Gregory Szorc [:gps]]

We have no plans of addressing this. It's been 4+ years without anyone wanting it, so I'm guessing the requirement went away.