[ckan-dev] Branching policy and standardizing on branch names

Seb Bacon seb.bacon at gmail.com
Thu Feb 10 13:02:33 UTC 2011


On 10 February 2011 12:13, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> Very minor thing but please, if you can, standardize on branch names
> (feature-{#}-my-name, defect-{#}-my-name}).
>
> I've also updated the existing Branching Policy wiki page to be up to
> date and more concise:
>
> <http://ckan.org/wiki/BranchingPolicy>
>
> One thing missing, and to be decided, is flow of changesets around
> actual repositories. I think we want to move away from 'svn' everyone
> pushes to main model to a dictator or dictator and lieutenants model:

Alternatively we could move towards a "continuous development" model
where we have complete test coverage, fast automated test builds, easy
deployment, feature flags and a "blame" functionality so that everyone
can be confident and take responsibility for their own code.

Pros and cons of both approaches.  The problem with dictator model is
bottleneck, things waiting around to be merged, becoming harder to
merge with time, etc etc.  The benefit is building in code reviews.

> http://whygitisbetterthanx.com/#any-workflow (of course here applied
> to mercurial!)
>
> Rufus
>
> PS: whygitisbetterthan... is wrong on at least 2/3 mercurial items
> where it claims git is better than hg :) (staging area - simple plugin
> and branching ...)

So far, I still find git easier to work with, but that is probably
mainly about familiarity.

Seb




More information about the ckan-dev mailing list