From users-return-5724-daniel=haxx.se@subversion.apache.org Wed Nov 3 10:18:35 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=-1.5 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,T_RP_MATCHES_RCVD 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 oA39IYaS032310 for ; Wed, 3 Nov 2010 10:18:35 +0100 Received: (qmail 34603 invoked by uid 500); 3 Nov 2010 09:18:24 -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 34595 invoked by uid 99); 3 Nov 2010 09:18:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Nov 2010 09:18:22 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS Received-SPF: pass (nike.apache.org: domain of jcorvel@gmail.com designates 209.85.214.171 as permitted sender) Received: from [209.85.214.171] (HELO mail-iw0-f171.google.com) (209.85.214.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Nov 2010 09:18:16 +0000 Received: by iwn33 with SMTP id 33so273981iwn.16 for ; Wed, 03 Nov 2010 02:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2/QyUR6KBNEFrcxeVK6LugGFk+aHCq9BcfKS4XLH3Is=; b=icI0XMcuMvZGePb+zb4mV5fClu+8D1rTeyS6xksqeAmYsY9xHzvBy8dmspE/jLyqEQ 5nnObs0lG98AAC499z40J0Sa7p1YttB7rq0M9zR6R/SXs8/Yb2Wn5DYW0exDZxJoN9cs X7D4X7Gyvdwbip8G2tcL2bLzYWIu9PCOhwHWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cra3ADbrazAVqJK+67NUPdKPfZXYFAgMyZjGAG3kTHeYiYYubSxhCuEBO9ZK09zO8j rpqtISjINm3mc6FXt0H8zpiFu/mCuuVrl/gJYDllRe1BjQp/iZGKseRB84KGTIAeb9aB YtrMeRgeciLPhB0r8u1zB51lpJaA8WTkanEqY= Received: by 10.231.59.12 with SMTP id j12mr3865786ibh.11.1288775874917; Wed, 03 Nov 2010 02:17:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.210.7 with HTTP; Wed, 3 Nov 2010 02:17:34 -0700 (PDT) In-Reply-To: References: <6680A70380E6BA44A2D94ED7085718EE28C28A42E2@ln1exc03> From: Johan Corveleyn Date: Wed, 3 Nov 2010 10:17:34 +0100 Message-ID: Subject: Re: mergeinfo not inherrited when I thought it should To: Pieter-Jan Busschaert Cc: Giulio Troccoli , "users@subversion.apache.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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]); Wed, 03 Nov 2010 10:18:35 +0100 (CET) X-Friend: Nope On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert wrote: > Hello, > > Here is some more information: > >>> Inside branch1/subfolder, we do a merge from trunk/subfolder. >> >> Do you mean trunk/project/subfolder here? > > yes > >> Anyway, branch1/subfolder does not have any mergeinfo, >> since the previous merge was done on branch1. So Subversion >> does not know that you have already merged the changes to line 1. > > Correct, but isn't SVN supposed to crawl up the tree to find > mergeinfo? I thought this was the most simple usecase of inherited > mergeinfo, which is described in various places, for instance here: > http://help.collab.net/index.jsp?topic=3D/faq/mergeinfo.html Yes, you are absolutely right. Mergeinfo is normally inherited, so any mergeinfo set on the branch1 folder applies to the entire subtree (and svn indeed crawls up the tree to find all the mergeinfo that applies). Except if the mergeinfo is marked with an asterisk '*', which means "non-inheritable mergeinfo". For more in-depth information about mergeinfo, see [1]. >> Merges from trunk to branch and vice-versa should always be done >> from the root of the project (in your case branches/project/branch1) > > I can not believe this is true. =A0I can not control the other users and > I have had reports of similar issues from a few different users here, > so it seems a real use case. Well, it's *recommended* to do merges always from the project root, but it's not required. SVN supports so-called "subtree merges" (which have the potential to only merge part of a revision). The reason it's recommended to do merges from the project root, is that it avoids explicit mergeinfo all over your tree. For every subtree merge, SVN records explicit mergeinfo on that subtree root. This means that that subtree will no longer inherit mergeinfo from higher up the tree. For this reason, explicit mergeinfo needs to be maintained all the time by SVN (because it will no longer crawl up from that point). Every subsequent merge at the project root causes those explicit-mergeinfo-paths to have their mergeinfo properties updated, even if they are not affected by the merge, which can be quite confusing to users. Other than that, subtree merges work just fine in SVN, just because of the explicit mergeinfo on the subtrees. (the upcoming 1.7 release will improve the situation a bit, IIUC: the not-affected-subtrees will no longer have their mergeinfo updated all the time, only if they are affected by the merge). >> I don't think so, as I think Subversion did the correct thing, given the= information it has. > > Well, I still think it did not do the correct thing, as it had more > info available than it actually used. > >> However, I recommend you to push for an upgrade of SVN, as I remember 1.= 5 was not particularly good with merging. > > I have just tested with 1.6.13 on a test pc and it behaves exactly the sa= me. > > > > By reading the details of inherited mergeinfo in the collabnet FAQ, > maybe the bug is because mergeinfo is not up to date in the working > copy and SVN uses that instead of contacting the repository. If this > is the case, I would expect SVN to give me a "please update" warning > when I do the merge command. Yes, maybe that's the problem. Can you retest this with an update at the right place, to see if the problem still occurs? Maybe you should check out the section "Mixed Revision Working Copies and Mergeinfo" in the above mentioned article [1], to see if it describes what you're seeing. If that's the case, you are probably right about the warning. I think this is being addressed in the upcoming 1.7 as well (see [2] and [3]). If the problem is something else, please try to come up with a simple reproduction recipe, starting with the creation of an empty repository (svnadmin create ...), demonstrating the problem. Cheers, --=20 Johan [1] http://www.collab.net/community/subversion/articles/merge-info.html [2] http://svn.haxx.se/dev/archive-2010-10/0000.shtml [3] http://svn.apache.org/viewvc?view=3Drevision&revision=3D1027970