Glen, My questions was more about managing risk. Sorry if it wasn't clear enough. My bad.
What I meant was, should all changes be committed to trunk first and then the release manager will decide whether it should be merged to branch or not? this is to make sure that a change will not destabilize the release. I wanted to know if sample code/documentation is exempted from this procedure. I think in my email " How about sample code? Do I have to fist put it on trunk and then merge to branch." was misleading and gave you the impression that I was thinking about checking into branch and not trunk. I should have been "can I check in low risk items to both trunk and branch w/o first checking into trunk and then get approved for a merge". Regards, Rajith On 7/23/07, Glen Daniels <[EMAIL PROTECTED]> wrote:
Rajith Attapattu wrote: > ok so documentation can be comitted to both trunk and branch. > How about sample code? Do I have to fist put it on trunk and then merge > to branch. > I hope not. > > I assume this restriction is only for code that can affect axis2 > functionality. > Support code/documentation can go in both. Hi Rajith! I'm not exactly sure what you're asking here... if you check something in that's new stuff, whether it be docs, sample code, changes to AxisEngine.java, whatever - that stuff SHOULD be checked in to trunk and merged over to the branch. There should never be a time where the branch is "more up-to-date" than the trunk. I assume SVN is smart enough to recognize identical commits to the trunk and the branch, so simply checking in identical changes on both should be OK also. Regardless, the changes should exist in both places UNLESS there really is something that is totally version-specific (such as release notes), in which case it can only be on the branch. Make sense? --Glen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
