On Dec 1, 2008, at 11:54 AM, Øyvind Harboe wrote:
Subversion makes it very easy to merge from trunk to branch. If _all_ of the changes made to trunk should be pulled into the branch, it can be done with 2 commands while recreating the branch takes 4. Someone should review the changes committed since the branch was made and make a list of items to be merged. Then, someone with commit access should use 'svn merge' to mergethose specific commits to the branch.The point is that 1.0 branch was cut too early, IMHO. That's not a problem. I think it is OK to try a svn version and then let it cool off. It it turns out it was a bad time to cut a branch, we can just cut some other time.This is why I advocated to cut some version in the *past* because it is easierto predict the past than the future. :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
There is never a good time to make a branch. That's why you choose tools that allow easy merging between branches and the trunk. I wouldn't say that the 1.0 branch was cut too early. It isn't entirely clear that all of the changes committed to trunk should be pulled back into the branch. Once a branch is cut, each commit to trunk should be evaluated for the branch. The evaluation should consider risk vs reward and only merge in changes that have high reward for the risk (i.e. if the risk is low and the reward is low, it's ok. If the risk is medium and the reward is high, it's ok. If the risk is high but the reward is medium, don't take it). That way things that improve the quality without introducing instability are merged into the branch. That methodology advocates cutting a stable branch relatively early to avoid destabilizing changes from making it into the release.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
