From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: Please don't use revision numbers on commit messages (and elsewhere). Date: Sat, 02 Apr 2011 07:20:49 +0100 Message-ID: References: <877hbfvwyo.fsf@wanadoo.es> <87sju2hoee.fsf@ambire.localdomain> <87pqp6vn3p.fsf@wanadoo.es> <874o6iicxp.fsf@ambire.localdomain> <83mxkapb2g.fsf@gnu.org> <87zkoat20x.fsf@wanadoo.es> <83liztyeed.fsf@gnu.org> <87ipuxu3hb.fsf@wanadoo.es> <87aag9tt7e.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1301725293 31215 80.91.229.12 (2 Apr 2011 06:21:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2011 06:21:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 02 08:21:29 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q5uDA-0008Rw-Kp for ged-emacs-devel@m.gmane.org; Sat, 02 Apr 2011 08:21:28 +0200 Original-Received: from localhost ([127.0.0.1]:55790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5uD9-0001Mq-SJ for ged-emacs-devel@m.gmane.org; Sat, 02 Apr 2011 02:21:27 -0400 Original-Received: from [140.186.70.92] (port=54908 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5uD2-0001HR-3u for emacs-devel@gnu.org; Sat, 02 Apr 2011 02:21:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5uD1-0006N1-15 for emacs-devel@gnu.org; Sat, 02 Apr 2011 02:21:20 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:41720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5uD0-0006MC-KP for emacs-devel@gnu.org; Sat, 02 Apr 2011 02:21:18 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q5uCy-0008B6-L9 for emacs-devel@gnu.org; Sat, 02 Apr 2011 08:21:16 +0200 Original-Received: from cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com ([92.232.137.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2011 08:21:16 +0200 Original-Received: from u.s.reddy by cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2011 08:21:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 87 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <87aag9tt7e.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138053 Archived-At: On 4/2/2011 1:03 AM, Óscar Fuentes wrote: >> >> Can you comment on whether this convention suits you? > > I don't get the part about the local branch. If you branch from trunk > when the tip revno is 10, then commit locally (revno 11) then commit > again locally (revno 12) mentioning your revno 11 on the commit message, > finally merge the changes into trunk which meanwhile advanced to revno > 15, this is how trunk looks like afterwards: > No, the trunk really looks like this: 16 merge uday's awesome feature into trunk 10.1.2 Fix bug introduced on revision 11 10.1.1 Implement awesome feature 15 someone else's changes 14 someone else's changes 13 someone else's changes 12 someone else's changes 11 someone else's changes 10 someone else's changes .... Notice that the merged branch revisions are numbered 10.x.y, not 16.x.y or 15.x.y. If the branch originated at revno 10 of the trunk, then its revisions are numbered 10.1.1, 10.1.2,.... That is how the DAG structure is represented. (I didn't realize this until Stephen Turnbull explained it to me last summer, here on emacs-dev!) The three components of the revision number are: base-revision . branch-id . branch-local-revision The base-revision is revision number where the branch diverged from the trunk. The branch-id is a unique number for the merged branch, just in case multiple branches based at revision 10 happen to get merged in due course. The branch-local-revision is the localized version of the revision number, i.e., 1 = 11-10, 2 = 12-10, ... So, doing that bit of arithmetic is all it takes to decode "revision 11". > 1. People do as they see. If you put revnos on trunk's commit messages > they get the message that it is okay to do that on their branches > too. Agreed. But as I have argued, it is okay for people to do it in their branches too. > 2. Related to the previous, it is undesirable to add exceptions to > policies. The same response as above. > 3. If you are inspecting the VC history on a branch and wish to see > where certain commit with revno X mentioned on a commit message, bug > report, etc fits on the context of your branch, you must go out of > your way to look up on trunk the revid of X. All you would need is your branch's history. I don't understand what you would find on the trunk that you don't have in your branch's log already. > 4. Generalizing the previous point: revids remain valid after a merge, > revnos don't. revid's remain textually valid. revno's remain mathematically valid. If it turns out to be a big problem, then we should probably write an emacs browser for bzr logs that does the conversions. Ideally, bzr people should have given us some way to write something like $r12 in the log entry, which could have been automatically translated to 10.1.1. But you know bzr people. They don't like to make life harder for the novices to help the experts. ------- Another possible way to write the revision references is to use relative numbers, i.e., to refer to revision 11 in revision 12, just say "revision -1". It is easy to write, and easy to understand as well. Cheers, Uday