SUBVERSION REINTEGRATE UPDATE

> reintegrate then all parent changes should have been merged to the > If you have done anything on the trunk this is odd/wrong to do a > 2) Do nothing in the new branch, don't even check it out > make the problem as simple as possible I did the following: I'm experiencing some especially odd behavior now. > We have been having a lot of problems trying to do -reintegrate merges Sorry I missed replying to a couple points at the bottom in the last reply.įrom: Paul Burba Ĭc: Brian Rieck users_at_

To: Brian Rieck 'Paul Burba' 'Greg Troxel'

Maybe that is unrelated to the problem at hand but I wouldn't describe my confidence in the health of the repository as high.Īs always - thanks for the help so far everyone.ġ) Just for the heck of it I'm going to try removing all merge info from trunk on the backup server to see what happens.Ģ) I'm going to re-restore the repo from backup and verify that the behavior is different before and after removing the self-referential mergeinfo from trunk.

SUBVERSION REINTEGRATE UPDATE

I find it odd that I would get the 'mixed-revision' error even though nothing could have changed on trunk, then doing a no-op svn update makes the error go away. So unfortunately there is something else or something more happening than just the self-referential merge info on trunk. tried to do a -reintegrate merge again and the 'mixed-revision' error goes away but svn wants to actually merge a bunch of stuff - adds, removes, conflicts - I think the list is different as I only recall conflicts before and now there are adds and removes- I will verifying this. I'm not sure how I could be out of date as I'm the only person with access to the backup server and I just committed all the changes. tried to do a -reintegrate merge and I got -> 'svn: Cannot reintegrate into mixed-revision working copy try updating first'. committing the prop changes from removing the mergeinfo references to trunk So after removing references to trunk in trunk's mergeinfo I: Then my plan was to remove the self-referential mergeinfo using a script that Geoff Rowell suggested. I have restored Tuesday night's backup to a test server and recreated the problem. In my situation, any branch that was created when that mergeinfo was present is completely hosed. I can see some self-referential svn:mergeinfo against trunk in your attachments. This breaks the wazoo out of any subsequent merges to or from trunk branch was created from trunk_at_389, but Subversion relies on the svn:mergeinfo when it’s present, rather than consulting the natural history, which results in it trying to apply 116-389 to the branch during the merge. The branch inherits trunk’s self-referential svn:mergeinfo in the copy. Ě branch is created from trunk_at_HEAD (let’s say HEAD = 389). Trunk gets self-referential mergeinfo added to it, i.e. This sounds very similar, if not identical, to a problem I’ve run into recently: Trent suggested in a reply to my post on the dev list that he thought that the problem could be caused by self-referential mergeinfo on trunk:

Subversion reintegrate