-----Original Message----- From: Stefan Sperling [mailto:s...@elego.de] Sent: 26 October 2011 11:29 To: James French Cc: users@subversion.apache.org Subject: Re: Behaviour of reintegrate in 1.7.1
On Wed, Oct 26, 2011 at 10:02:17AM +0100, James French wrote: > I was prompted to give 1.7.1 a shot when a reintegrate merge task > turned up where the destination checkout was sparse, which was not > possible at all in 1.6. If memory serves me correctly with 1.6 you > could reintegrate into you working copy provided that the development > branch had been fully synced up to the same revision as the working > copy. This is correct. > Once the reintegration was complete you could update to merge in > any further checkins and then checkin yourself. Not sure what you mean here, this is very unclear. Update which working copy? Merge further revisions from which branch to where? After you've merged into working copy you can't check in until that working copy is up to date, hence updating to get latest changes which are then 'merged in' to your working copy. I shouldn't have used the term 'merge' as it was confusing. >Am I correct in this? See http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3c20110720124721.ga7...@ted.stsp.name%3E for a more precise explanation. Thanks. I solved my immediate problem by doing a 2 way merge and bypassing the reintegrate checking. > With 1.7.1 (tortoisesvn), it seemed that this might not be the case. > The dev branch was synced up to revision 10769 and the destination > working copy was alsio at 10769 (using update to revision). When I > tried to reintegrate svn complained that revisions beyond the revision > of the working copy had not been synced up, and as other people > checked in this number appeared to grow. No idea. Can you please show the exact error message you got? Sorry, its gone. It was a load of missing revisions on a load of different files and folders. >From where I stand it sounds as if you simply haven't closed all gaps in the revision ranges already synced from trunk to the branch. But maybe this is a separate problem related to the sparse working copy? Can you show us how to reproduce the problem starting from an empty test repository? I'm not really in a position to do that right now but as I evaluate 1.7 I intend to build up a test suite so I can really get to grips with how things are working. Sorry about that, its a bit lame but work deadlines and all... > I did not look much further than this, but this seemed fishy so I > thought I'd ask here. We're used to loads of hassle with mergeinfo and > reintegrate merges (this is one area I'm praying that svn 1.7 will > greatly improve). The merge info has been such a headache over the > last few years that we're all a bit confused as to what's correct, > what's buggy, what's left over from previous bugs... I hope that 1.7 will improve things for you. Note that benefits are most visible with branches created and maintained exclusively with 1.7 clients. I am sure it will. Thanks for all your help, and for tortoisesvn.
