On 08/06/2010 11:15 AM, Lee Bieber wrote: > I'm OK with most of this, I found it very confusing when you stepped in > to help yesterday when I had to step away for a few minutes. I think its > better to let one person play through. We should make sure that when we > take on a merge we are committed to seeing it all the way through (my > fault for having to step away). > > But something is still not in sync. We shouldn't be seeing "n versions > removed" messages from bzr when we push to build, staging or trunk. Also > when I tried to pull from build/staging/trunk to my local branches this > morning I got the dreaded "these branches have diverged" message. For > safety sake I just started over fresh.
Agree. Whenver we get that, something has gone off a bit. > Here is a short summary of what we have documented on the wiki page - > http://drizzle.org/wiki/Merging_Code Please let me know if there is > something here that is out of step in this process: > > Build > > * bzr pull to make sure you are in sync I always start with "bzr pull --overwrite lp:drizzle" to make sure I'm starting with a fresh copy of trunk. > * bzr merge <branches> > * bzr commit > * build and test > * bzr push lp:drizzle/build > > Staging > > * bzr pull to make sure you are in sync > * bzr merge lp:drizzle/build > * bzr commit > * build and test > * bzr push lp:drizzle/staging > > Trunk I do not do this last section - if you followed the above, you should at this point be able to pull directly from staging and push that directly to trunk. > * bzr pull to make sure you are in sync > * bzr merge lp:drizzle/staging > * bzr commit > * build and test > * bzr push lp:drizzle > > > On 8/5/10 10:54 PM, Brian Aker wrote: >> Hi! >> >> I thought I would explain a few more bits about merges. >> >> Lets say you have patches 23,24,25 in your local tree. Just push them to >> build. As long as none of them fail you are ready for staging. >> >> For staging I typically do a rollup of the three. So they will all become >> "23" with subrevision numbers (if you are ever worried that the rollup to >> staging has something that has not full gone through build, read the >> comments for uniqueness). The valgrind report should always be the indicator >> of whether or not something should move to staging (ie you can look at it >> and see if the latest passed or not). >> >> Once you have a rollup in "staging" you can push another set to build. Are >> there any issues with this? >> >> If staging fails you will have to over write anything you pushed after the >> rollup you pushed to staging. So you risk doing wasted work, but normally it >> is not a lot of wasted work. >> >> Is there anything that shouldn't be rolled up? >> >> Yes. If you have a major patch, something that touches a lot of files (lets >> call it 10+ ), unless it is just a simple "rename" patch, you should >> probably run it through the system by itself. I would also recommend that >> for the most part if you have a stack of Stewart's patches that are just >> for the embedded engine, I would just put them in one merge. >> >> Should you ever use the build tree to fix a patch? IE build is broken and >> you want to push a "fix" for it. I would try to keep this to a minimum. For >> instance it is ok if it is a build related item. Valgrind/etc should >> probably be fixed in local trees. I've made the mistake plenty of times of >> trying to fix in build, it typically does not work. >> >> What about helping someone out? >> >> I think it would be nice if others could promote it (we all go out to eat, >> have other things to do, etc...). My only concern is that this could be >> confusing. I've felt comfortable sometimes doing this in the last week, and >> I know that I have sometimes not. I am also aware that it can make someone >> feel "well, they were going to do it...". So I would love to hear other >> people's thoughts on it. Personally I like to see stuff moving through as >> quickly as possible, but there is a balance in this as well. >> >> Thoughts? >> >> Cheers, >> -Brian >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~drizzle-merge >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~drizzle-merge >> More help : https://help.launchpad.net/ListHelp >> > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at [email protected], and delete the original message. > Your cooperation is appreciated. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-merge > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-merge > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~drizzle-merge Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-merge More help : https://help.launchpad.net/ListHelp
