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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
