[Svnmerge] Lost in Properties

[Thomas F. O'Connell]

On Mar 7, 2007, at 7:39 PM, Raman Gupta wrote:

> Thomas F. O'Connell wrote:
>> Some background about my setup is in this thread:
>>
>> http://www.orcaware.com/pipermail/svnmerge/2007-January/000807.html
>>
>> I never satisfactorily resolved the issue from that thread. I'm  
>> worried
>> about data loss that would affect my ability to keep track of changes
>> local to any given branch, but I'm also worried about getting into a
>> state of conflict that is beyond my ability to resolve, which is my
>> current concern.
>
> See below.
>
>> Here is the use case I'm trying to achieve. If there are better
>> practices out there that use svnmerge.py, then I'm all ears.
>>
>> trunk
>> branches/branch-1
>> branches/branch-2
>> ...
>> branches/branch-n
>>
>> With the style of development for this project, each of the  
>> branches is
>> typically a major feature branch, all of the changes of which  
>> eventually
>> need to land on trunk. But trunk needs to be left in a state from  
>> which
>> releases can easily be created. Most minor bug fixes are performed
>> directly on trunk. Often, features from the branches will land on  
>> trunk
>> and then be enhanced in the same branch. And it's nice for branch- 
>> x to
>> pick up the changes that landed on trunk from branch-y.
>
> I think this is a pretty normal process and one that svnmerge.py
> should be able to easily handle, if handled with care.
>
>> But I came into this process with the original svnmerge (the Bourne
>> shell edition). I upgraded to svnmerge.py based on community
>> recommendations. I've used it successfully in the above scenario thus
>> far without error until now, although when I started, rather than  
>> using
>> -b for svnmerge.py avail and svnmerge.py merge, I was manually  
>> leaving
>> out a lot of the svnmerge-related revisions. This might've  
>> contributed
>> to my current problem.
>
> Yes, I would guess (I have to because you still haven't given me a
> proplist --verbose as I requested earlier) that your trunk has merge
> information for itself, because one of the merge revisions from a
> branch was mistakenly merged back to trunk at some point (which could
> easily happen if you were not using the -b flag).
>
> Does an "svn pl --verbose trunk" show the trunk itself as one of the
> sources? If it does, then that explains why you were having the
> problem in the other thread -- when you create a new branch, and try
> to use svnmerge.py on it, the integrated property (which contains
> trunk as a source) gets copied to the branch. So svnmerge.py thinks
> your new branch already has trunk as a source.
>
>> Honestly, I'd like to wind up resetting everything based on the trunk
>> and possibly re-initializing all branches, but I'm not even sure  
>> about
>> the safest way to do this. I've got some changes in the branch  
>> currently
>> exhibiting the problem that I don't want to lose revision history  
>> for.
>
> I think this is a good idea since it seems like your svnmerge.py
> information is pretty fubar'ed. What I would do is this (untested):
>
> 1) Figure out which revisions have already been merged between trunk
> and every branch, and vice-versa. Ditto for revisions that have not
> been merged (and therefore are available) but should be blocked. The
> svnmerge-integrated and blocked property will reflect these values,
> plus some administrative revisions, when you're done.
>
> 2) "svn pd svnmerge-integrated" and "svn pd svnmerge-blocked" on every
> trunk and branch.
>
> 3) On the trunk, execute "svnmerge.py init <branch>" for every branch.
>
> 4) On the trunk, execute "svnmerge.py --record-only -r <revlist> merge
> -S <branch>" for every branch, where revlist is the list of already
> merged revisions from step 1. Include in this list the revision
> created in step 2.
>
> 5) On the trunk, execute "svnmerge.py -r <revlist> block -S <branch>"
> for every branch, where revlist is the list of revisions from step 1
> that should be blocked.
>
> 6) Repeat steps 3, 4, and 5 for every branch, with trunk as source.
>
> 7) From now on, always use -b when merging.
>
>> If I can provide any specific information about my setup, please  
>> let me
>> know, and I'll be happy to do so.
>
> As I said before, pl --verbose on your trunk and problematic branches
> would help.
>
> Cheers,
> Raman

Raman,

Thanks so much for the help. Sorry I overlooked the request for the  
proplist. Here they are:

trunk:
Properties on '.':
   svnmerge-blocked : /branches/branch-1:2954,2982-2983 /branches/ 
branch-2:2663,2804,2848
   svnmerge-integrated : /branches/ 
branch-3:1-2931,2934-2989,2994-3001,3008 /branches/ 
branch-1:1-2953,2955-2981,2984 /branches/ 
branch-2:1-2847,2849-2894,2899-3094 /branches/stage:1-2528 /branches/ 
branch-4:1-2833 /trunk:1-2527
   svk:merge : b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/ 
branch-5:2449
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/stage:2644
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/branch-6:2632
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/branch-7:2471

branch-3 (which is where I experience the conflict if I try to merge  
from trunk):
Properties on '.':
   svnmerge-blocked : /branches/branch-2:2663,2804,2848 /trunk: 
2932,2955,2984
   svnmerge-integrated : /branches/branch-2:1-2847,2849-2894 / 
branches/stage:1-2528 /branches/branch-4:1-2833 /trunk: 
1-2931,2933-2954,2956-2983,2985-2992
   svk:merge : b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/ 
branch-5:2449
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/stage:2644
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/branch-6:2632
b4057098-830f-0410-9e9d-90cfdc2c32ef:/branches/branch-7:2471

To be honest, I wasn't even aware of the svk branches prior to  
putting this together. I suspect that the previous developer never  
landed those changes where I can see them. I don't see branches 5 6  
and 7 in my working copy.

--
Thomas F. O'Connell

optimizing modern web applications
: for search engines, for usability, and for performance :

http://o.ptimized.com/
615-260-0005