From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10211292009.AA20871@clio.rice.edu> Subject: Re: _Exit function [PATCH] To: djgpp-workers AT delorie DOT com Date: Fri, 29 Nov 2002 14:09:46 -0600 (CST) In-Reply-To: <200211291750.gATHofw21252@envy.delorie.com> from "DJ Delorie" at Nov 29, 2002 12:50:41 PM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > But that way loses the version history, compared with moving the ,v > > files. How about a copy to the new place, followed by a cvs remove > > of the old? > > If you do that, it still corrupts old tags because then you get extra > files you shouldn't get. add/remove is the least bad of the many bad > solutions to this problem. Besides, the file in the new location > should *not* have a history *there*. Copying the history of the > deleted file is misleading. > > Note that your initial add should include a note as to where you're > moving from, of course, and you can still "cvs log" a removed file > too. In this case it doesn't make any difference (on the old tags) because snprintf doesn't have any (other than HEAD) since it's never been in a release. For snprintf() the history isn't very interesting anyway (copyright changes). In general I prefer to use the standard cvs tools (delete it from the old place, add it to the new place, reference old location if someone wants to look at history) instead of playing games in the repository directly. The cvs documentation talks about the pros and cons of each way of moving. In this case (and probably everything we would want to move) there's no huge reason to do anything special. I wouldn't be suprised with new directories it might not be best to nuke our old trees and do a clean checkout, however, when this is all done ...