From users-return-20480-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Fri Jan 3 03:17:02 2014 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 65CAE1036D for ; Fri, 3 Jan 2014 03:17:02 +0000 (UTC) Received: (qmail 50958 invoked by uid 500); 3 Jan 2014 03:16:59 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 50837 invoked by uid 500); 3 Jan 2014 03:16:55 -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 50830 invoked by uid 99); 3 Jan 2014 03:16:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jan 2014 03:16:53 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.215.41] (HELO mail-la0-f41.google.com) (209.85.215.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jan 2014 03:16:48 +0000 Received: by mail-la0-f41.google.com with SMTP id c6so2654323lan.14 for ; Thu, 02 Jan 2014 19:16:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=fEIxeBcDFgY/tI0115YWm0R35ImjIV9zTuMhavppcBY=; b=RXW7UbHee9xJ5dqH+BueTXFRlB16OSTHOAzuvvX47FeRRB4k/525C5tkAfE8qRv32I ePXvm1k5MeM9Z1r0SLuaJdSi4Z5B4ys9xV/UMsne3rPnFDH/Cp/YVPFWhx7drSsVlhAc N25nCV+X1AkqptqIAzGb3twyG3jbka/A5FZpMtn7Kdva9tYEzt8J7xS+T8t3nml1kxRN u2x9+AYVwAMlzATzKng7iPSo7fj6k6pb6kbIL4T0BUXm+lrvd1MY3sTsH5S1WEUQwnw2 ZXURE7ZUj6T6/+kVt7eCwsFcaKHvr31rbu73e8E5jKwmyKFAl1oascUezeVFKIwGc6cw OwYA== X-Gm-Message-State: ALoCoQk1bjGr39IBkpBAQ9Kt3DIejhCG0uEiUArTrc/XCgUPsCd9GnTp+vyRk0s1qOO+NpLN90gx MIME-Version: 1.0 X-Received: by 10.152.6.201 with SMTP id d9mr23403034laa.25.1388718984321; Thu, 02 Jan 2014 19:16:24 -0800 (PST) Received: by 10.114.21.169 with HTTP; Thu, 2 Jan 2014 19:16:24 -0800 (PST) Date: Thu, 2 Jan 2014 22:16:24 -0500 Message-ID: Subject: Keyword expansion from merged changes From: James Hanley To: "users@subversion.apache.org" Content-Type: multipart/alternative; boundary=089e013d1a94c0ee2304ef08559c X-Virus-Checked: Checked by ClamAV on apache.org --089e013d1a94c0ee2304ef08559c Content-Type: text/plain; charset=ISO-8859-1 I've used the Rev keyword in some of our code, and we noticed that there may be a use case gap for the Rev/Revision and possibly Id keyword. As expected the keyword gets updated with any checkin, but there may be a need to have a merge-history aware version these keywords. Meaning that the Rev shown from a merge isn't the actual checkin of the merge, but the change origin of the merge. So the use case would be branching a project P from the trunk to do some work, them merging those changes back. In its current form, the rev takes the revision of the merged checkin rather then the origin of the merged change. We see a need for this capability of having a merge-history aware keyword, and one way to accomplish this without adding yet another keyword would be to have the existing keywords support some kind of argument like options. For example, when setting for the Rev keyword (as it works right now), simply set Rev for the property svn:keywords, but if the user really wanted Rev to indicate the delta origin of the rev they would use rev.g or perhaps rev -g in the svn:keyword entry... The disadvantage with this meathod vs creating either new svn keywords or having the options embedded directly in the keyword referenced within the file is that you cannot have two different revs in the same file. Fuel for though? -Jim --089e013d1a94c0ee2304ef08559c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've= used the Rev keyword in some of our code, and we noticed that there may be= a use case gap for the Rev/Revision and possibly Id keyword.

As exp= ected the keyword gets updated with any checkin, but there may be a need to= have a merge-history aware version these keywords.=A0 Meaning that the Rev= shown from a merge isn't the actual checkin of the merge, but the chan= ge origin of the merge.

So the use case would be branching a project P from the trunk to do som= e work, them merging those changes back.=A0 In its current form, the rev ta= kes the revision of the merged checkin rather then the origin of the merged= change.

We see a need for this capability of having a merge-history aware keywo= rd, and one way to accomplish this without adding yet another keyword would= be to have the existing keywords support some kind of argument like option= s.

For example, when setting for the Rev keyword (as it works right = now), simply set
Rev
for the property svn:keywords, but = if the user really wanted Rev to indicate the delta origin of the rev they = would use
rev.g
or perhaps
rev -g
in the svn:keyword= entry...

The disadvantage with this meathod vs creating eithe= r new svn keywords or having the options embedded directly in the keyword r= eferenced within the file is that you cannot have two different revs in the= same file.

Fuel for though?
-Jim
--089e013d1a94c0ee2304ef08559c--