Hi Bob Thanks for your response. What does elided mean ? We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a "svn merge" and "svn commit"
How do we stop top posting and adhere to the rules ? We're new. Thank you Sincerely On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer <bob.arc...@amsi.com> wrote: > > Hi Johan, Bob and all > > > > We took your suggestion and it still fails in that > > 1- when we try to merge again at the root level > > (goals: > > a- to move subtree merge done previously to the working copy root level > so > > that the past merge can be traced at the root level using "svn mergeinfo > -show- > > revs merged) > > > > svn merge -c 498 https://test.com/svn/root /path/to/root > > > > But when we do a svn status, all other untouched files and > folders (unrelated to > > the revision number) are also touched. > > > > svn status -u > > M 506 src/ap > > M 506 src/ap/k.java > > : > > : > > > > We then commit. > > > > We performed the above steps for several other revision numbers and > still get > > the same svn status -u output for those files and folders when executing > those > > other subsequent revision numbers. > > > > > > What are we doing wrong ? > > What are the changes to those files? I assume mergeinfo is being elided > from all those files? If so, that is something that you want to happen. > Once that is done the first time, all your merge info will be in the root > folder and you won't see this any more. > > > (Stop top posting!!!) > > > > > Thanks all > > sincerely > > > > > > > > On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer <bob.arc...@amsi.com> wrote: > > > Hi All > > > > > > We have a revision that contains a few changed files on the trunk: > > > r345 > > > /usr/ext/a.java > > > /usr/ext/b.java > > > > > > We like to merge this a branch working copy. > > > Can we perform multiple merge svn with the same revision number ? > > > We have a reason to do that; We know it doesnt make sense in this > > > simple example. > > > > > > ie can we have 2 merge svn executions and still produce the same > > > result as a simple merge execution. > > > meaning > > > > > > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java > > > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java > > > > > > as opposed to > > > svn merge -c 345 https://test.com/svn/root/src/usr/ext > > > > > > > > > Thanks all. > > The resulting commit would probably be the same... although I expect the > > merge info would be applied to the files rather than the folder. Give > your > > simple example a try in a test repo. > > > > BOb > >