From users-return-6124-daniel=haxx.se@subversion.apache.org Fri Nov 19 18:26:36 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DS_FRIEND autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id oAJHQZ6V025170 for ; Fri, 19 Nov 2010 18:26:36 +0100 Received: (qmail 43840 invoked by uid 500); 19 Nov 2010 17:26:27 -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 43833 invoked by uid 99); 19 Nov 2010 17:26:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Nov 2010 17:26:26 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS Received-SPF: pass (nike.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Nov 2010 17:26:17 +0000 X-Envelope-From: stsp@stsp.name Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id oAJHPtoh000801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 18:25:56 +0100 Received: from ted.stsp.name (stsp@localhost [127.0.0.1]) by ted.stsp.name (8.14.3/8.14.3) with ESMTP id oAJHPtiY027200; Fri, 19 Nov 2010 18:25:55 +0100 (CET) Received: (from stsp@localhost) by ted.stsp.name (8.14.3/8.14.3/Submit) id oAJHPt9q015738; Fri, 19 Nov 2010 18:25:55 +0100 (CET) Date: Fri, 19 Nov 2010 18:25:55 +0100 From: Stefan Sperling To: Johan Corveleyn Cc: Daniel Becroft , subversion Subject: Re: URL-only renames adds svn:mergeinfo property Message-ID: <20101119172555.GA19097@ted.stsp.name> Mail-Followup-To: Johan Corveleyn , Daniel Becroft , subversion References: <20101119111010.GA31643@ted.stsp.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Virus-Checked: Checked by ClamAV on apache.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Fri, 19 Nov 2010 18:26:36 +0100 (CET) X-Friend: Friend On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote: > I don't see why it matters that it's a "sub-branch". It's still a > (grand-)child of mybranch, so can perfectly inherit that mergeinfo. > AFAIU it only needs explicit mergeinfo if it starts to deviate from > the mybranch root (e.g. if something is (sync-)merged directly to the > sub-branch). Or am I missing something? Hmmm.. I don't see any reason either. Explicit mergeinfo could probably be created later when the subtree actually becomes a merge target. I guess the current logic in the code simply doesn't account for the case where the copy destination is a child of the source? Not sure. Stefan