Thanks I have read that doc, but it was a while back so I'll re read it. The issue with the problems we are seeing is that I'm coming in late to this situation so most o of these I haven't seen first hand. I also discovered that people weren't using --reintegrate and push from branch to trunk. That can easily result in extra conflicts.
Here's what I'm telling people to do now PULL svn co URL-branch path-to-workspace svn mergeinfo URL-trunk path-to-workspace --show-revs eligible > eligible_revs.txt svn merge --accept postpone URL-trunk path-to-workspace svn mergeinfo URL-trunk path-to-workspace --show-revs eligible > what-is-left-to-merge.txt Repeat until there's nothing left that's eiligible. The fact that the merge sometimes stops and demands the user resolve before it can proceed with the additional ranges through me for a bit. I was still operating in 1.4 mental mode. I didn't realize that SVN will break up the job based on the merge history to as few merge ranges and paths as possible. SVN will stop merging if one of those creates a conflict and a subsequent needs to modify the file. (Makes complete sense, I can't postpone in that case). I believe that this case is what people were calling a conflict on mergeinfo data. So, the description wasn't accurate (at least I hope this is the case). PUSH svn co URL-trunk path-to-workspace svn mergeinfo URL-branch path-to-workspace --show-revs eligible > eligible_revs.txt svn merge --reintegrate --accept postpone URL-branch path-to-workspace svn mergeinfo URL-branch path-to-workspace --show-revs eligible > what-is-left-to-merge.txt ... you may need to resolve conflicts and repeat the ... merge until there are no more change (see below for details) svn ci -m "merge from trunk to branch using command: <insert merge command here>" local-path I think the show-revs will give my users greater confidence about determining when they are done. We also plan to add a hudson build jobs that checks the elibigle revision queue from trunk to each feature branch and nags people if it gets too long. On Tue, May 11, 2010 at 7:10 AM, Julian Foad <julian.f...@wandisco.com>wrote: > Hi Peter. > > The mergeinfo "corruption" may be real, but just as likely it doesn't > work the way you expect, or Subversion is being asked to perform > combinations of merging that it doesn't support automatically. It seems > likely that even if there is some "corrupt" merge info, that is only a > part of the problem. It sounds like you might benefit from > understanding better how Subversion's merging works "on the inside" > which will give you the rationale for what it can and can't do "on the > outside". > > If that's the case, have a look right at the end of this article > <http://www.collab.net/community/subversion/articles/merge-info.html> at > the list of "Parting Thoughts" which says how to stick to the kinds of > merging that Subversion can cope with. (That article is mostly the > intricate detail of svn:mergeinfo which you really don't want to know.) > Also, WANdisco has an upcoming free training webinar on "Branching and > Merging" which could be useful if you can wait till July 14: > <http://wandisco.com/webinar/subversion/training>. > > As for the specific issues you mention, I can't comment much without > seeing the precise detail. It would be a good idea to raise each one as > a separate query, giving a full transcript of input and output and what > you think is wrong. > > Regards, > - Julian > > > -- Peter Kahn citizenk...@gmail.com pkahnp...@aim http://www.google.com/profiles/citizenkahn Awareness - Intention - Action
