I really appreciate your help, but I'm still trying to comprehend.

If I do the `svn propdel -R svn:mergeinfo; svn revert .` in my branch, I wind 
up clearing out mergeinfo on 8000+ files:
 ( I collected a `svn pg svn:mergeinfo` before and after the operation. Using 
wc -l to get a sense of how much change happened)
[charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$ wc -l 
mergeinfo.before.txt 
8374 mergeinfo.before.txt
[charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$ wc -l 
mergeinfo.after.txt 
59 mergeinfo.after.txt

If I focus on looking into what changed for only the file that I used for an 
example at the start of this thread, I see that its mergeinfo is wiped out and 
not replaced.

[charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$ grep 
ports/lsm/lsmclient/test/cukes/features/1_package_update mergeinfo.before.txt 
ports/lsm/lsmclient/test/cukes/features/1_package_update - 
/6WINDGate/branches/zorro_trunk_merge/ports/lsm/lsmclient/test/cukes/features/1_package_update:21398-23471
/6WINDGate/production/aries_1.1.1/ports/lsm/lsmclient/test/cukes/features/1_package_update:21842,21867,21906,22087,22270,22334
/6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_update:15746-19001,19597-25912
[charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$ 
 [charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$ grep 
ports/lsm/lsmclient/test/cukes/features/1_package_update mergeinfo.after.txt 
[charletr@ariesbld DUAL_SSL_Inspection-mergeinfo-cleanup]$

The reason I find this confusing is because I assumed my goal is to get branch 
to undersand that a missing merge revision has actually been merged. This seems 
to go the other way and make branch forget a great deal of what has been merged.

Did you envision that my next step would be to check this in (to branch)? Or to 
merge trunk into branch again?

--
Ricky Charlet


-----Original Message-----
From: Andreas Stieger [mailto:andreas.stie...@gmx.de] 
Sent: Thursday, May 21, 2015 9:53 AM
To: Charlet, Ricky
Subject: RE: reintegrate merge failing because "can only be used if revisions 
<snip> were previously merged", but it's a lie (I think?)

The suggestion related to a merge source path (a branch).
Also note the revert to retain the main mergeinfo.

Am 21.05.2015 18:27 schrieb "Charlet, Ricky" <ricky.char...@hp.com>:
>
> Thanks Andreas,
> I've been playing around with the mergeinfo deletions as you suggested. I 
> have not yet committed anything. It appears to me, if I do this at the top 
> level of my trunk working copy, I will lose almost all my merge history. That 
> seems pretty bad... 
>
>
> --
> Ricky Charlet
>
> -----Original Message-----
> From: Andreas Stieger [mailto:andreas.stie...@gmx.de]
> Sent: Wednesday, May 20, 2015 11:23 PM
> To: Charlet, Ricky
> Cc: users@subversion.apache.org
> Subject: Re: reintegrate merge failing because "can only be used if 
> revisions <snip> were previously merged", but it's a lie (I think?)
>
> You may have explicit subtree merge tracking information which differs from 
> that on what is normally the root of the working copy and merge operation. 
> These accumulate on actual merges on subtrees as well as copy operations to 
> resolve tree conflicts. While it is a valid use case it is more likely to 
> cause issues. 
>
> To diagnose: 
> svn propget -R svn:mergeinfo
>
> To remove explicit subtree merge tracking information: 
> svn propdel -R svn:mergeinfo
> svn revert . 
>
> Andreas
>
> Am 21.05.2015 02:51 schrieb "Charlet, Ricky" <ricky.char...@hp.com>: 
> > 
> > Howdy,
> > 
> > I have a trunk and a feature branch. Time has come (it was long, over a 
> > year) to reintegrate back into trunk. I have subversion 1.8 on both server 
> > and client (though a year ago, we were using 1.6 server and client). 
> > 
> > I have recently (like yesterday) merged trunk to branch successfully. It 
> > passes verification and sanity testing. I like the branch. 
> > 
> > From within an up-to-date trunk working copy, if I attempt the merge branch 
> > back to trunk I get some complaints: 
> > [charletr@ariesbld trunk]$ svn merge 
> > ^/6WINDGate/branches/DUAL_SSL_Inspection . --dry-run --accept 
> > postpone
> > svn: E195016: Reintegrate can only be used if revisions 15725 through 26003 
> > were previously merged from 
> > https://csvnrose-pro.rose.hp.com:18180/svn/tpt-6wind/6WINDGate/trunk to the 
> > reintegrate source, but this is not the case: 
> >   
> > 6WINDGate/branches/DUAL_SSL_Inspection/ports/lsm/lsmclient/test/cuke
> > s/
> > features/1_package_update
> >     Missing ranges: 
> > /6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_u
> > pd
> > ate:19595
> >   6WINDGate/branches/DUAL_SSL_Inspection/ports/xtrap/scripts
> >     Missing ranges: /6WINDGate/trunk/ports/xtrap/scripts:21872
> >   
> > 6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.
> > 0/
> > systems/linux/kernel/constellation-2_6
> >     Missing ranges: 
> > /6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/kernel
> > /c
> > onstellation-2_6:17549,18282
> >   
> > 6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.
> > 0/
> > systems/linux/user/constellation-2_6
> >     Missing ranges: 
> > /6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/user/c
> > on
> > stellation-2_6:17549
> > 
> > [charletr@ariesbld trunk]$
> > 
> > 
> > Soo... that's a bit hard to believe because I did just recently merge trunk 
> > to branch. Furthermore, if I go into my branch working copy and attempt to 
> > merge an exact change (let me pick revision 19595 as an example because 
> > it's first in the listing above), nothing happens: 
> > [charletr@ariesbld DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . 
> > --accept postpone  -r 19595:19595 [charletr@ariesbld 
> > DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . --accept 
> > postpone -r 19594:19596
> > --- Recording mergeinfo for merge of r19595 through r19596 into '.': 
> > U   . 
> > [charletr@ariesbld DUAL_SSL_Inspection]$ svn stat -q 
> > [charletr@ariesbld DUAL_SSL_Inspection]$ svn ci [charletr@ariesbld 
> > DUAL_SSL_Inspection]$
> > 
> > 
> > FYI, here is the view of mergeinfo from my trunk and branch: 
> > [charletr@ariesbld trunk]$ svn propget svn:mergeinfo 
> > ports/lsm/lsmclient/test/cukes/features/1_package_update
> > [charletr@ariesbld trunk]$
> > 
> > [charletr@ariesbld DUAL_SSL_Inspection]$ svn propget svn:mergeinfo 
> > ports/lsm/lsmclient/test/cukes/features/1_package_update
> > /6WINDGate/branches/zorro_trunk_merge/ports/lsm/lsmclient/test/cukes
> > /f
> > eatures/1_package_update:21398-23471
> > /6WINDGate/production/aries_1.1.1/ports/lsm/lsmclient/test/cukes/fea
> > tu
> > res/1_package_update:21842,21867,21906,22087,22270,22334
> > /6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_u
> > pd
> > ate:15746-19001,19597-25912 [charletr@ariesbld DUAL_SSL_Inspection]$
> > 
> > Notice that 19595 is, infact, missing from branch's mergeinfo. 
> > 
> > 
> > 
> > In summary, A recent merge from trunk to branch suceeded, trunk cannot 
> > reintegrate because it claims that some change sets are not merged to 
> > branch, attempts to merge those exact change sets into branch produce a 
> > no-op, mergeinfo on branch confirms those change sets are missing. 
> > 
> > I'm stuck... any ideas what to try next? 
> > 
> > 
> > --
> > Ricky Charlet
> > Software Dev / Routing Dude: Aries team, Roseville CA 
> > ricky.char...@hp.com
> > USA: 916.785.2090
> > 

Reply via email to