Ticket #81 (new enhancement)

Opened 1 year ago

Last modified 1 year ago

better branch handling

Reported by: warner Assigned to: warner
Priority: major Milestone: 0.8.0
Component: buildprocess Version: 0.7.5
Keywords: branches Cc:

Description

just a few notes on branch handling improvements:

  • the Waterfall should get a branch= argument, to limit the display to specific branches.
  • the "current status" should get the same. Saying "the tree is currently broken" really means "trunk is currently broken", and a failing build on some random side branch should not cause people to think that trunk is having problems
  • likewise, 'try' builds and anything that uses a patch should not count against trunk. This might mean that all builds with patches should be filtered out when using branch=, or maybe we need some additional flag.

Branches could be objects internally. They have a short name (which is used on the waterfall, in the checkout step, and is also what branch= is compared against), and they have a VC-specific string (which is combined with the repository base to figure out how to get code from this branch).

There could be a BranchManager? that's associated with the VC checkout step, or maybe with the ChangeSource. The SourceStamp?'s .branch attribute should be a Branch object, or a short name that the BranchManager? could turn into a Branch object.

Change History

09/28/07 13:39:13 changed by warner

with the new web-status changes coming up in 0.7.6, most pages will accept one or more branch= query arguments, to restrict the display to just those builds which used one of the given branches. This gets us 90% of the way there.

This means all branches are referenced by a string name, which has two potential problems:

  • branches that have slashes in them (i.e. SVN BASE/branches/foo layouts will have a branchname of "branches/foo") might upset HTTP proxies that don't like to see slashes in the query argument (I think I've stumbled across this sort of bug in the past, but maybe I'm just imagining it)
  • our convention of None (the python None type) meaning "trunk" makes it impossible to filter on just trunk builds.

To fix the latter, I'm thinking of making the branch-filtering code treat the string "None" as equivalent to a sourcestamp.branch value of None. Or maybe allowing the string "trunk" to match either .branch=="trunk or .branch==None, since that would be way easier to use.

This still doesn't address how branches are handled by the VC code, but I think all of our current VC systems basically treat branches with string names anyways, and the only potential weirdness is with subdirectory-based branches having somewhat verbose names like "branches/foo".

It also still doesn't address 'try' builds making it look like trunk was broken.

10/16/07 08:53:03 changed by warner

  • milestone changed from undecided to 0.8.0.

I've implemented the bit that handles branch=="trunk" by matching on either "trunk" or None, so trunk builds are not as much of a problem as they used to be.

Subdirectory-based branching and 'try' builds are still issues.