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 Jeremias Maerki
