From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andre Spiegel Newsgroups: gmane.emacs.bugs Subject: [Fwd: Re: [21.2]: VC/RCS changes default branch when dealing with branch re vision] Date: 15 Jun 2002 13:21:57 +0200 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <1024140120.3461.41.camel@eagle> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-+M1k6TEuAZ/lXkvsxD+z" X-Trace: main.gmane.org 1024140253 7219 127.0.0.1 (15 Jun 2002 11:24:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 15 Jun 2002 11:24:13 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17JBfA-0001sK-00 for ; Sat, 15 Jun 2002 13:24:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JBf8-0006pC-00; Sat, 15 Jun 2002 07:24:10 -0400 Original-Received: from [194.73.242.4] (helo=wmpmta02-app.mail-store.com) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17JBdG-0006mU-00 for ; Sat, 15 Jun 2002 07:22:14 -0400 Original-Received: from stu1ir100-137-122.ras.tesion.net ([213.182.137.122]) by wmpmta02-app.mail-store.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20020615112152.KGST18066.wmpmta02-app.mail-store.com@stu1ir100-137-122.ras.tesion.net> for ; Sat, 15 Jun 2002 12:21:52 +0100 Original-To: bug-gnu-emacs@gnu.org X-Mailer: Ximian Evolution 1.0.5 Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:2054 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:2054 --=-+M1k6TEuAZ/lXkvsxD+z Content-Type: text/plain Content-Transfer-Encoding: 7bit Here is a copy of my reply to Simon's message. --=-+M1k6TEuAZ/lXkvsxD+z Content-Disposition: inline Content-Description: Forwarded message - Re: [21.2]: VC/RCS changes default branch when dealing with branch re vision Content-Type: message/rfc822 Subject: Re: [21.2]: VC/RCS changes default branch when dealing with branch re vision From: Andre Spiegel To: "Marshall, Simon" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1024139335.3519.30.camel@eagle> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.5 Date: 15 Jun 2002 13:20:11 +0200 On Fri, 2002-06-14 at 18:16, Marshall, Simon wrote: > Emacs has set the default branch revision in RCS. AFAICS this happens > when I C-u C-x v v to change to edit the branch revision. Perhaps Emacs > has (or had) good reason to change the default branch, but I think it is > wrong. C-u C-x v v is the only way to checkout a branch revision, e.g., > for editing, but it doesn't mean I want the branch revision to be the > default revision in RCS. Thanks for your analysis. This behavior is fully intentional, though. The reason is, as we put it in the Emacs manual, that after you switch to a branch, you "stay" on it for subsequent editing. And yes, Emacs achieves this by setting the RCS default branch. To go back to the trunk in Emacs (and clear the default branch), you'd have to do C-u C-x v v RET once. You could of course also do this from the shell using rcs -b; I'm not sure if plain `co' also has a corresponding option. The reason we set the default branch is that without it, at the beginning of a new session, Emacs would always think it is working on the trunk, even if you've left the branch version checked out, and wanted to stay on the branch. Emacs _can_ detect that if you use version headers ($Id$) in your file. In that case, setting the default branch wouldn't be necessary, but we decided to do it because the feature needs to work even in the absence of version headers. This has been the behavior ever since RCS branches were supported, i.e. for more than five years. So far, people seem to have been content with it. Can you make a compelling case against it? I'm open to suggestions, but as far as I can think now, the current behavior does make a lot of sense. --=-+M1k6TEuAZ/lXkvsxD+z--