From users-return-1103-daniel=haxx.se@subversion.apache.org Thu Feb 18 22:26:22 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o1ILQK8N031394 for ; Thu, 18 Feb 2010 22:26:21 +0100 Received: (qmail 81491 invoked by uid 500); 18 Feb 2010 21:26:15 -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 81483 invoked by uid 99); 18 Feb 2010 21:26:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2010 21:26:15 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rvanoo@gmail.com designates 209.85.211.189 as permitted sender) Received: from [209.85.211.189] (HELO mail-yw0-f189.google.com) (209.85.211.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2010 21:26:07 +0000 Received: by ywh27 with SMTP id 27so1435948ywh.22 for ; Thu, 18 Feb 2010 13:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=xwSRmbg1AoVEdvMjyW8gfZGkcHcyrtfy3hzo9SXn2P4=; b=UY6prrjLDwORSoQWTapTUp3sI2SJ6h8CF0FIG3z4JxU523Me65mDjoL7+511JiN83l Kl7eZyD8gDLXjLj+SdTw0C1bodbC0di+MWVoD3nhnzKP4Ku3lTm+QOJmhTdVLOJyu1iX pO94DXL359iXpTeynbUrTMramK1VEbfg8UH9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NfHfuL2bTunKuAqhmoVVw4pi1c3NVZhx+7JUFjmflvrcklZSdm1GzoTnla6CnZGGxm lAJ+wpG1SXNH8eyoF/hJ+y2YBapkRNYa061qtPATgeiQ0dbRnni+z+nCHRFj8/is0xzT DFggzEt4OK6a/3rW/yHEaB6VWz8v3bFBlVSpE= MIME-Version: 1.0 Received: by 10.150.119.17 with SMTP id r17mr314140ybc.9.1266528346550; Thu, 18 Feb 2010 13:25:46 -0800 (PST) In-Reply-To: <898896FC-D4BF-4CC6-ACD4-8665FDC9CF74@jacobweber.com> References: <898896FC-D4BF-4CC6-ACD4-8665FDC9CF74@jacobweber.com> Date: Thu, 18 Feb 2010 16:25:46 -0500 Message-ID: <8dd4dbc21002181325r7111f32u8afd450ca5a50bab@mail.gmail.com> Subject: Re: Partially reintegrate changes From: Rob van Oostrum To: Jacob Weber , users@subversion.apache.org Content-Type: multipart/alternative; boundary=000e0cd6ce0231b1c1047fe69c73 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd6ce0231b1c1047fe69c73 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 18, 2010 at 1:42 PM, Jacob Weber wrote: > Stein Somers: > > I see some self-refenertial mergeinfo in our /trunk, after lots of > > merges to and from. Maybe I explicitly added it with a record-only in > > some state of confusion. But it doesn't scare me at all. It would only > > matter if you explicitly merged /trunk to /trunk. And then, as far as I > > can tell, it would only cause svn merge to do less than it does without > > the self-refenertial mergeinfo, and as far as I can tell a > > self-referential foward merge doesn't do anything anyway. > > > It does scare me a little. When I have self-referential mergeinfo, it > causes problems with "svn log -g" (show merged revisions). It gets confused > and shows me ALL revisions in the branch, from the time it was created. So > the command takes forever, and returns way too much data. > > Jacob So if and when this does occur and you can't live with the inconvenience, just "svn propedit svn:mergeinfo" and manually clean up any references to self. That should be safe AFAIK. R. --000e0cd6ce0231b1c1047fe69c73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 18, 2010 at 1:42 PM, Jacob Weber <jacob@jacobweber= .com> wrote:
Stein Somers:
> I see some self-refenertial mergeinfo in our /trunk,= after lots of
> merges to and from. Maybe I explicitly added it with a record-only in<= br> > some state of confusion. But it doesn't scare me at all. It would = only
> matter if you explicitly merged /trunk to /trunk. And then, as far as = I
> can tell, it would only cause svn merge to do less than it does withou= t
> the self-refenertial mergeinfo, and as far as I can tell a
> self-referential foward merge doesn't do anything anyway.


It does scare me a little. When I have self-referential mergeinfo, it= causes problems with "svn log -g" (show merged revisions). It ge= ts confused and shows me ALL revisions in the branch, from the time it was = created. So the command takes forever, and returns way too much data.

Jacob

So if and when this does occur and = you can't live with the inconvenience, just "svn propedit svn:merg= einfo" and manually clean up any references to self. That should be sa= fe AFAIK.

R.
--000e0cd6ce0231b1c1047fe69c73--