Interesting. In fact, while svnmerge is (IMO) a wonderful tool for keeping a temporary branch in sync with the Trunk, its behaviour seems to be more erratic when it comes to merging back that branch into the Trunk. Good to know for the future.
Thanks for the details, Vincent Jeremias Maerki wrote: > I had tons of conflicts and conflict markers within conflict markers. > Some of the code simply came out wrong and I wasn't able to fix the > merge result in reasonable time. Since I've merged all changes in trunk > into the branch before the merge back I expected this to go more > smoothly. In the end I was much more comfortable with the results with a > simple non-svnmerge merge. And it took me much less time than the first > attempt with svnmerge. Maybe I've done something wrong but I just > followed the tutorial. Shrug. I hope SVN's own merge tracking to come > will work a little better. > http://subversion.tigris.org/merge-tracking/ > > On 17.04.2008 19:56:14 Vincent Hennebert wrote: >> Just curious: what didn’t work exactly? >> >>> Author: jeremias >>> Date: Mon Apr 14 05:01:06 2008 >>> New Revision: 647745 >>> >>> URL: http://svn.apache.org/viewvc?rev=647745&view=rev >>> Log: >>> svnmerge didn't work for me in this case. Remove svn merge info. >>> >>> Modified: >>> xmlgraphics/fop/trunk/ (props changed) >>> >>> Propchange: xmlgraphics/fop/trunk/ >>> ------------------------------------------------------------------------------ >>> --- svnmerge-integrated (original) >>> +++ svnmerge-integrated Mon Apr 14 05:01:06 2008 >>> @@ -1 +1 @@ >>> -/xmlgraphics/fop/branches/Temp_ProcessingFeedback:1-615152 >>> /xmlgraphics/fop/branches/fop-0_95:1-636405,636407-638388 >>> /xmlgraphics/fop/trunk:1-611115 >>> +/xmlgraphics/fop/branches/fop-0_95:1-636405,636407-638388 >>> /xmlgraphics/fop/trunk:1-611115 -- Vincent Hennebert Anyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
