The one's you merged manually can be marked as applied, rather than blocked.
Sometimes svnmerge takes so long it appears to have failed, it wouldn't surprise me if it took an hour or two to do all the merges. Rupert On 15/06/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Martin Ritchie wrote: > The list of revisions to merge is getting quite large. If the M2 > committers can check their revisions should be merged to trunk. If not > can you use svnmerge block to remove them from the list of available > revisions. > > $ svnmerge avail -S ../../branches/M2 > 536253,536449,536584-536585,537171,538079,538098,539470,539476,539481,539484,539594,539783,539788,54 > > 0169,540511,541247,541920,542484,542789,543496,544109,544422,544508,544866,545146,546096,546190,5464 > > 41,546458,547178,547627 > > I shall merge some of the ones that I have done. Really the merges > should be done in order to minimise the potential for conflicts. > > If no-one has any objections I can just merge all of the changes.. > provided it all merges cleanly :) I'm the culprit for many of these I'm afraid. My earlier attempts to use svnmerge were abandoned when the script seemed to go into a loop, consuming lots of memory and bringing my laptop to a halt without actually producing anything. I will try again, unless some kind soul who knows what they're doing wants to block them for me! 536253,536449,536584-536585,538079,538098 were all merged to trunk manually. 540511 is not currently going to be applied to trunk. I'll check up on 540169 and 537171 but both were 1-line fixes so I can merge by hand and block them from the list also.
