cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: asf/vpc branch merge
Date Fri, 10 Aug 2012 20:19:29 GMT
As I'm not a git expert, I would appreciate any help from the community in
figuring out what is the best way to merge vpc branch into master.

Couple of ways I can think of:

1) git checkout master; git merge -s recursive -Xignore-space-change vpc

Puts all commits from the vpc that are differnt from master, to the master


* no tree rebase happens
* easier to revert individual commits if they cause any issues
* Have 0 conflicts after the merge is done (just tested on my local branch)
* Very close to vpc branch, so reduces the chances for regression bugs
(vpc branch was tested)


* harder to track down all VPC commits as they've been happening for a
couple of months, and appear in the git log on the date they were
originally submitted.

2) Do interactive rebase on master from vpc and squash all the commits
into one

git checkout master; git rebase -i asf/vpc


* Easier to see all VPC changes as they come as a part of a single commit


* Requires rebase which leads to lots of conflicts.
* Not sure if there is an option to revert an individual commit happened
as a part of squashed commit.

I personally prefer way 1) as it doesn't lead to conflicts + leaves less
chances for regression bugs as the asf/master structure becomes very
similar to the structure of asf/vpc branch, and this branch was tested.
But let me know if anybody sees any downsides of doing the merge this way
and can suggest a better way.

Thank you,

On 8/10/12 10:33 AM, "Alena Prokharchyk" <>

>Considering that there is a code freeze happening soon, and as the main
>part for VPC feature development is complete + the VPC code
>has been well tested by cloudStack QA engineers, it's time to discuss
>merging the asf/vpc branch into asf/master. At this point its too hard to
>break it to several components-to-merge as there were too many single
>commits for the last couple of months from 7 developers involved in the
>process + we were doing the daily merges with master branch in order to
>keep asf/vpc branch up to date. It makes it hard to componentize at this
>point without running into lots of rebase conflicts
>So most likely it will be done as a single merge if
>the merge gets approved by the community. We would highly
>appreciate any help involving code/documentation review as well as any
>other suggestions on how to make this particular merge safer and smoother.
>And the suggestions made towards the merge process in general, will all be
>addressed in the future.
>We've tried to keep vpc branch in sync with asf/master by performing daily
>merges from master branch to vpc, so there shouldn't be too many
>conflicts. The VPC code went through several rounds of QA including the
>regression testing for existing network components. Most of the VPC code
>resides in the new classes added as a part of the feature; but some
>existing Network related code got some changes and can be considered for
>the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
>particular as well as some Agent APIs and cloudStack UI). The VPC FS
>contains the reference to new classes (including client/agent APIs)
>created for the VPC feature (see the link below).
>Functional specification:
>Engineer participated in VPC development:
>Sheng Yang - S2SVPN implementation
>Alena Prokharchyk - Client/Agent APIs,
>Anthony Xu - All VirtualRuter script changes + feature implementation for
>Xen resource
>Kelven Yang - Implementation for VmWare resource
>Sonny Chhan/Jessica Wang/Brian Federle - UI component
>QA test cases execution matrix:
>I'm well aware the 4.0 will be branched on Monday, so once the merge is
>approved, I can do the merge over the weekend including doing basic
>regression for the networking key components on the merged branch.

View raw message