Opened 7 years ago

Last modified 3 years ago

#1773 assigned enhancement

deprecate 'default branch'

Reported by: dustin Owned by:
Priority: major Milestone: 0.9.+
Version: 0.8.3p1 Keywords: bzr, cvs, darcs, git, hg, p4, svn
Cc: in3xes@…

Description (last modified by sa2ajj)

The concept of a 'default branch' causes huge pain, with no gain. Let's see if we can make it go away:

  • ChangeSources? should always set c.branch to something
  • schedulers should require an explicit branch or branches
  • Source steps should require an explicit branch or branches

For backward compatibility, all of these should have parameters that can make them act the old way.

Change History (16)

comment:1 Changed 7 years ago by in3xes

  • Cc in3xes@… added

comment:2 Changed 6 years ago by Dustin J. Mitchell

  • Resolution set to fixed
  • Status changed from new to closed

remove BK. Fixes #2198.

Fixes #1773. Fixes #891. Fixes #1715.

Changeset: 5fe8217bab7f0facdd8f17625ecdb16a809f7d9a

comment:3 Changed 6 years ago by dustin

  • Keywords bk removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

..well, fixed for BK by virtue of removing BK support, but still open for the other VC's

comment:4 Changed 6 years ago by dustin

  • Milestone changed from 0.8.7 to 0.8.+
  • Status changed from reopened to assigned

comment:5 Changed 5 years ago by tom.prince

Git actually does have a notion of a default branch, as distinct from master. (And we've had some support for it since 0.8.6).

comment:6 Changed 5 years ago by dustin

True, and that makes a lot of sense in the changesource, but sourcestamps should have an explicit branch (which may be what "default" pointed at when the change was created).

comment:7 Changed 5 years ago by tom.prince

That doesn't work for force builds. Or buildbot sendchange.

comment:8 Changed 5 years ago by dustin

Hmm, sounds like we need a got_branch property..

comment:9 Changed 5 years ago by Tom Prince

Git: Document that not specifying a branch gets the default remote branch.

This has been the behaviour since 0.8.6, so fix the documentation to match.

Refs #1773.

Changeset: 95ccb18a5dc8d667f154b82abcfb32862961437d

comment:10 Changed 5 years ago by Tom Prince

Git: Document that not specifying a branch gets the default remote branch.

This has been the behaviour since 0.8.6, so fix the documentation to match.

Refs #1773.

Changeset: 95ccb18a5dc8d667f154b82abcfb32862961437d

comment:11 Changed 5 years ago by Tom Prince

Git: Document that not specifying a branch gets the default remote branch.

This has been the behaviour since 0.8.6, so fix the documentation to match.

Refs #1773.

Changeset: 95ccb18a5dc8d667f154b82abcfb32862961437d

comment:12 Changed 3 years ago by dustin

  • Milestone changed from 0.8.+ to 0.9.+

Ticket retargeted after milestone closed

comment:13 Changed 3 years ago by sa2ajj

  • Description modified (diff)

We do not seem to have .branch set to something all the time.

The current implementation of SVNPoller sets it to None if the branch is trunk.

comment:14 Changed 3 years ago by sa2ajj

Discussion on IRC was about SVN and defaultBranch. One of the users said: this is one of the reasons I'm still using the old-style SVN step

comment:15 Changed 3 years ago by sa2ajj

It looks like for the

<root>/
   trunk
   branches/
      branch1
      branch2

layout, the workaround would be %(src::branch:~trunk)s.

comment:16 Changed 3 years ago by sa2ajj

(I'll update the docs with this specific example.)

Note: See TracTickets for help on using tickets.