On Tue, 2010-05-11, Peter Kahn wrote: > 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). Hi Peter. That looks good. I hope this means most or all of the problems you mentioned will go away, but please re-raise if there still are problems. ... > PUSH > svn co URL-trunk path-to-workspace > svn mergeinfo URL-branch path-to-workspace --show-revs eligible > > eligible_revs.txt Actually, "mergeinfo" is not useful here; it will show misleading results, as it shows what changes are eligible for the "pull" kind of merging. I don't think "mergeinfo" has a mode for showing what a re-integrate merge will do. Instead, for this "push" case you could use: svn diff --summarize URL-branch URL-trunk or svn diff --summarize path-to-branch-workspace path-to-trunk-workspace (you can't mix a URL with a local working-cpopy path in a diff --summarize). > 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 you meant "merge from branch to trunk ..." here.) > 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. Heh, that's an interesting idea that I haven't heard of before :-) - Julian > 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
