Answer to 3: Tomas, you won't find it hard to keep trunk up to date with M2 for .net stuff when you are the only committer making changes to it.
Here's a quick guide: Check out the whole source tree (branches and trunk). cd to /qpid/trunk/qpid, svnmerge has been set up to track at this point, so all merge operations are performed in that directory. Make some changes to .net on M2 branch and commit them on that branch. Now, to see what changes are available to merge to trunk do: svmerge avail --source ../../branches/M2/ You should see the revisions you just made, perhaps as part of a longer list. If the list is really long post a reminder on the dev-list asking people to keep their merges up to date. Currently the list is: 531859,531865,531908,531917,531937,531989,532002,532372,532466 Suppose your revision is 531859, to merge it onto trunk do (you may need to svn up on trunk first, svnmerge only works on clean copies). svnmerge merge --source ../../branches/M2/ -r531859 Hopefully this will go smoothly, without any conflicts. If there are conflicts you can either abandon the merge by doing doing a revert on trunk, or edit the files by hand to resolve the conflicts. Once you've merged to your satisfaction, commit trunk. Generally speaking, if all changes are merged, trunk does not diverge from M2, and merges are always done in revision order with none skipped, then you will get no conflicts. I've had conflicts in the past because I just merged my changes, when their were older changes made by others that were not merged. When the older ones were merged they conflicted with my newer ones. Which is also why its important to keep up to date with your merges. Rupert On 26/04/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
I Finally got my apache account created today! Thanks to all for that. I've, of course, read the new committers guide in the apache site, but still wanted to ask a couple of general questions: 1- When can we start actually making commits to the qpid tree? 2- Do we have any rules or conventions in place for commits? (i.e. commit message format and so on). Anything we need to be aware of to avoid screwing things up? 3- Like many others, I'd start working on the M2 branch, but we need to keep the trunk in sync as well. Could someone offer any suggestions on what the best way to do this would be? Is it better to do so by hand, using svnmerge or what? If the latter, can anyone offer any suggestions as to how to use it? (I've seen http://www.orcaware.com/svn/wiki/Svnmerge.py of course). 4- Once I'm ready to start doing my own commits, I'd thought I'd start with the JIRA's for which I've already submitted patches and that are pending. These are: QPID-435: Fix for Headers Exchange test QPID-441: Fix handling of bounced messages QPID-398: SSL Support for .NET Client Does that sound OK? BTW, one final question: Who is supposed to close an issue in JIRA? At least on the .NET client side, they seem to remain open forever, even when patches have been proposed and even committed already into the trunk... Thanks again, Tomas Restrepo http://www.winterdom.com/weblog/
