Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0FA807129 for ; Wed, 26 Oct 2011 09:02:50 +0000 (UTC) Received: (qmail 99501 invoked by uid 500); 26 Oct 2011 09:02:48 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 99358 invoked by uid 500); 26 Oct 2011 09:02:47 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 99351 invoked by uid 99); 26 Oct 2011 09:02:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2011 09:02:46 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 86.12.140.205 is neither permitted nor denied by domain of James.French@naturalmotion.com) Received: from [86.12.140.205] (HELO mail1.naturalmotion.com) (86.12.140.205) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2011 09:02:40 +0000 From: James French To: "users@subversion.apache.org" Date: Wed, 26 Oct 2011 10:02:17 +0100 Subject: Behaviour of reintegrate in 1.7.1 Thread-Topic: Behaviour of reintegrate in 1.7.1 Thread-Index: AcyTvfXuXb3h11EKTdywEa0YXFq/rg== Message-ID: <950618E0D00138499BE7CC487EBF646D66FF58D19C@WOODCHUCK.NM.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_950618E0D00138499BE7CC487EBF646D66FF58D19CWOODCHUCKNMlo_" MIME-Version: 1.0 --_000_950618E0D00138499BE7CC487EBF646D66FF58D19CWOODCHUCKNMlo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, Firstly, thanks for all the enormous effort on svn 1.7.x, and for all the g= reat support. I have high hopes for 1.7. Its great to see all those .svn fo= lders banished. 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 i= n 1.6. If memory serves me correctly with 1.6 you could reintegrate into yo= u working copy provided that the development branch had been fully synced u= p to the same revision as the working copy. Once the reintegration was comp= lete you could update to merge in any further checkins and then checkin you= rself. Am I correct in this? With 1.7.1 (tortoisesvn), it seemed that this might not be the case. The de= v branch was synced up to revision 10769 and the destination working copy w= as alsio at 10769 (using update to revision). When I tried to reintegrate s= vn complained that revisions beyond the revision of the working copy had no= t been synced up, and as other people checked in this number appeared to gr= ow. 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 m= erges (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 p= revious bugs... Oh I should say that this is using server version 1.6.17 and the merging wa= s performed on Windows 7. Cheers, James --_000_950618E0D00138499BE7CC487EBF646D66FF58D19CWOODCHUCKNMlo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi guys,

 

First= ly, thanks for all the enormous effort on svn 1.7.x, and for all the great = support. I have high hopes for 1.7. Its great to see all those .svn folders= banished.

 

I was prompted to give 1.7.1 a shot when a reintegrate merge t= ask turned up where the destination checkout was sparse, which was not poss= ible at all in 1.6. If memory serves me correctly with 1.6 you could reinte= grate into you working copy provided that the development branch had been f= ully synced up to the same revision as the working copy. Once the reintegra= tion was complete you could update to merge in any further checkins and the= n checkin yourself. Am I correct in this?

 

With 1.7.1 (tortoisesvn), it se= emed that this might not be the case. The dev branch was synced up to revis= ion 10769 and the destination working copy was alsio at 10769 (using update= to revision). When I tried to reintegrate svn complained that revisions be= yond the revision of the working copy had not been synced up, and as other = people checked in this number appeared to grow.

 

I did not look much furth= er than this, but this seemed fishy so I thought I’d ask here. WeR= 17;re used to loads of hassle with mergeinfo and reintegrate merges (this i= s 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...

&n= bsp;

Oh I should say that this is using serve= r version 1.6.17 and the merging was performed on Windows 7.

=

 

Cheers,=

James

= --_000_950618E0D00138499BE7CC487EBF646D66FF58D19CWOODCHUCKNMlo_--