Hi,
Rajani Karuturi wrote:
In my first email, I mentioned a youtube url[1] which is a google tech talk by
Laura Wingerd [2] of Perforce Software
I recommend watching it as well. (its a 55 min video).
[1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
[2] http://www.perforce.com/blog/author/lwingerd
~Rajani
Thanks for sharing this again Rajani, I saw the video it was insightful.
Here are the slides: (link on youtube was broken)
http://web.archive.org/web/20061019021704/http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf
Let me share the key points from the shared talk:
- The speaker uses analogy of ease of driving cars on complex layout of
roads to developing software using a SCM.
- She recommends a mainline model which could speed up development and
release process. (refer the slides) We have branches -- mainline
(master), release (release branches) and development (feature work,
refactoring etc).
- Tofu scale: released/stable branches are firmer, unstable/master ones
are soft.
- She defines a baseline protocol: the soft branches are those which are
not tested and development work is going on, the firm ones are those
which are set to release or are already released or are live. The
protocol is to let the commit/changes flow from soft to firm branches
wrt to a baseline (master) only when they firm-er or tested and
continually changes flow from firm ones to soft ones (i.e. you rebase or
cherry-pick often from firm branches to soft ones). Change flows between
branch and baseline
- Always accept stable changes over destabilizing change
- She suggests to view the branches wrt baseline as a map, where changes
follow the baseline protocol and fix on an old trickle downs to
chronological release branches, then to baseline (master) and to rest of
the feature branches continually.
- She spoke about module, file tree etc. which I think is not relevant
for git users. We've git submodules and subtrees but IMO it's out of the
scope unless we want to split our repo.
- Merge down, copy up: She shares an interesting approach to deliver
feature work/project to firmer baseline branch which requires you to
first get all the changes from baselines (master & above, in git terms
that would be merge/rebase or cherry-picking from master to feature
branch) and then copy the files from the feature branch to baseline (not
merge). Then test and have the code/files in baseline (master).
My thoughts and suggestions:
- We adapt and adopt the baseline protocol (discuss?) wrt ACS
- We don't commit on master directly, break master. In future, have
master to be stable enough for anyone to branch off and work.
- Anyone fixing anything on master or other release/QA branches creates
a feature/topic branch and work on it, and merge/cherry-pick changes
back to upper branches only when that branch is well tested.
- Feature branches branch off master or other feature branches, not
release branches. Bug fix branches branch off from the oldest release
branch (on which we need to fix it) and the test fix lands to that
branch and subsequent release branches and then to master and other
feature branches.
- Suggestion for a better release protocol: All releases have tags. We
value tags more than release branch names. A vote is requested on a
release branch's commit with a version plus -RC, -beta and other
suitable name tag. Once vote is passed, the tag is the version number
this is the actual release. Git allows multiple tags can be on a commit
so we're good. Developers have freedmo to land but only bug fixes (once
fully tested) on release branches from a bugfix branch branched off from
the release branch or (by cherry-picking from) older release branches.
Then the bugfix lands to master and other feature branches continually.
This would also require that tags are immutable (you don't change/delete
them once created and pushed). IMHO this will speed up development process.
- One thing I'm still struggling with is working with branches/releases
which has fair amount of refactoring and rearchitecture work, which is
where changes would need to be manually ported and fixed. I don't have
any idea how to deal with it automatically, with git or any other tool.
On 09-Jul-2014, at 3:52 am, Sebastien
Goasguen<run...@gmail.com<mailto:run...@gmail.com>> wrote:
This is also a good read, against cherry-picking (back to Rajani's original
point):
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
(even wondering if Rohit did not send this to the list already…)
I do not remember sharing this, but I've read posts like this before and
I think it's just the author's opinion and not universal truth.
In my experience, if you rebase your source branch and cherry pick on
target there is no issue or conflicts (as suggested by this articles).
If merge/rebase is required I prefer no-ff and ignore-whitespace flags.
Merging IMHO is a quick and easy solution but it clutters the history,
while cherry-picking is great tool to sample out small subset (I'm not
saying backport 1000s of commits using cherry-picking) of changes from a
topic or feature branch and also useful to backport changes, it fails at
keeping the same commit id for a fix/issue (i.e. when you cherry pick
they are added to target branch as new commits).
Sometimes both may not work, and things have to be backported manually
to branches/releases which feels like developing different software
products.
I think when our RMs cherry-pick from master to release branches
(current or older), they are back-porting changes so cherry-picking is a
valid tool (in which case merging is evil I think).
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure
Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those of
Shape Blue Ltd or related companies. If you are not the intended recipient of this
email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email
in error. Shape Blue Ltd is a company incorporated in England & Wales.
ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue
is a registered trademark.
