From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: 20 Oct 2004 06:56:00 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <871xftd2nj.fsf@floss.red-bean.com> References: <20041020105027.GA17283@fencepost> Reply-To: kfogel@red-bean.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098273604 18732 80.91.229.6 (20 Oct 2004 12:00:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 20 Oct 2004 12:00:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 20 13:59:55 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CKF8E-0006Z8-00 for ; Wed, 20 Oct 2004 13:59:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CKFFc-00024S-Sm for ged-emacs-devel@m.gmane.org; Wed, 20 Oct 2004 08:07:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CKFDF-0001DI-Ew for emacs-devel@gnu.org; Wed, 20 Oct 2004 08:05:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CKFDA-0001C9-Vv for emacs-devel@gnu.org; Wed, 20 Oct 2004 08:05:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CKFD9-0001BQ-7d for emacs-devel@gnu.org; Wed, 20 Oct 2004 08:04:59 -0400 Original-Received: from [207.115.63.58] (helo=pimout7-ext.prodigy.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CKF5R-0006fI-37 for emacs-devel@gnu.org; Wed, 20 Oct 2004 07:57:01 -0400 Original-Received: from floss.red-bean.com (adsl-66-73-170-230.dsl.chcgil.ameritech.net [66.73.170.230]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i9KBu0jO215192 for ; Wed, 20 Oct 2004 07:56:00 -0400 Original-Received: from kfogel by floss.red-bean.com with local (Exim 3.36 #1 (Debian)) id 1CKF4S-0001yc-00 for ; Wed, 20 Oct 2004 06:56:00 -0500 Original-To: emacs-devel@gnu.org Emacs: because extension languages should come with the editor built in. In-Reply-To: Original-Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28657 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28657 Lars Magne Ingebrigtsen writes: > Miles Bader writes: > > I think this is generally considered a very bad thing to do. It's > >much safer (if less exciting) to just do the old cvs add+rm thing, > >and make the first commit log in the new location "renamed from foo". > > But then we lose the log. > > > The reason it's bad, as I understand it, is that it essentially > >changes history; I'm not entirely sure of the all the user-visible > >repercussions, but I'm not sure I want to find out the hard way... > > Hm... I don't quite follow you. The CVS tree is (almost) just a > bunch of ,v files. Miles's point is that by moving (or copying) a ,v file from one place to another, we create a history in the new place that was not actually there in reality. For example, if there is a tag V1_RELEASE on a revision in the ,v file, then someone attempting to check out the tree as of the tag V1_RELEASE will get a file in a location that did actually exist at the time the V1_RELEASE tag was made. (And if the ,v file was moved, instead of copied, the V1_RELEASE checkout will fail to contain a file that it should contain!) The usual solution is this: 1. Manually *copy* the ,v file from the old place to the new place. 2. Use 'cvs rm' to "remove" it from the old place (actually just marks the head revision as dead and puts the ,v file into CVS's Attic, thus preserving history) That's a compromise. It creates some new false history, but at least it preserves all of the old history. Old tags and branches will have all the files they should have, they'll just have a bit more besides. -Karl