From owner-freebsd-hackers Fri Feb 2 11:10:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02148 for hackers-outgoing; Fri, 2 Feb 1996 09:09:27 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA02045 for ; Fri, 2 Feb 1996 09:09:07 -0800 (PST) From: haury@sagem.fr Received: from relay1.fnet.fr (relay1.fnet.fr [192.134.192.129]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id AAA04819 for ; Fri, 2 Feb 1996 00:33:45 -0800 Received: from sagem.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA28522; Fri, 2 Feb 1996 09:32:36 +0100 (MET) Message-Id: <199602020831.JAA02040@sagem.fr> Subject: Re: CTM: evolutions of ctm To: hackers@FreeBSD.org Date: Fri, 2 Feb 1996 09:31:17 +0100 (MET) In-Reply-To: from "Richard Wackerbarth" at Feb 1, 96 10:51:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk This mail is an answer to Poul-Henning Kamp & Richard Wackerbarth mails about CTM Extract from my original mail (haury@sagem.fr) : > before working on a file , CTM first checks for the existence > of the file #ctm. If this file exists, CTM works on it instead. Poul-Henning Kamp replies: >Hmm, what if we make it .ctm then, would that be better ? It's not a bad idea. You have just to be carefull because '.ctm' is already used as temp file for edit process (Fn, FE) - since it's quite tricky, I have declared this suffix with my '#ctm' one in ctm.h to avoid any problems in case of future modification. The chose of '#ctm' is yours (I fact you have spoken about '#CTM' in the Handbook). What's true, it's not really easy to use '#ctm' into a Makefile (you often need to escape # ). Richard Wackerbarth wrote: >2) However, maintaining multiple versions of a tree in the same location >leads to problems. I am working of a scheme to allow the source to be on CD >ROM and only the modified portions need to be on the HD. This approach can >also work for the case that you are addressing with the kludge #ctm. Normally the union file system is here to do that - Unfortunatly the union fs does not work on FreeBSD (true in 2.1-R, I haven't test it again on -current) >3) Your proposed solution only allows for one derived version of the tree. >I suggest that there is a good argument for avoiding that constraint. > >Instead of having one source tree, I advocate that we have (at least) two. >The first is the "reference" which is maintained by ctm. However, this is a >pure source tree. You NEVER modify it. >The second tree is the "local" tree. It has all the modified sources (and >the objects). It seems difficult to check "automagicalyr" if a file you have modified has changed in the -current. The job is done with my top Makefile. > [deleted] > >need not take up much space because you do it all with symbolic links. (See >lndir) > >If we adopt this strategy,and I suggest that we do, everything looks >cleaner. If you want links from your tree to the reference for your ease of >access, they are easy to generate and do not affect the makefile logic. Well, you need sometime to make local changes to get the -current official tree to compile before having the official correction (the last time was the 'lsdev' problem : I have applied Thomas Neumann patches before getting the official correction, now I have droped my local modification). >tree as needed. Consider this senario. > >1) Start with the CD ROM (on say /cdrom/FreeBSD/src) >2) Create your update tree ( mkdir /pub/FreeBSD/2.1) >3) Populate it with the source (ln -s /cdrom/FreeBSD/src /pub/FreeBSD/2.1) >4) Now maintain it with ctm (cd /pub/FreeBSD/2.1 ; ctm 5) When ctm realizes that it needs to modify src/usr.bin/someprog/main.c > it will replace the symbolic link with a directory and populate that >directory with the appropriate links. > >What do you think of that approach? > Union fs should be the best choice for that. It's broken, the sources seems to be not so "obvious" and I don't have enough time to check the problem. :-( -- =Christian Haury (Christian.Haury@sagem.fr) --------------------------------------------------------- | SAGEM Eragny - Avenue du Gros Chene - Eragny BP 51 | | 95612 Cergy Pontoise Cedex - France | | phone : +33 (1) 34 30 53 93 | telex : 607387F | | fax : +33 (1) 34 30 50 28 | teletex : 933-130731770 | ---------------------------------------------------------