Date: Fri, 2 Feb 1996 09:31:17 +0100 (MET) From: haury@sagem.fr To: hackers@FreeBSD.org Subject: Re: CTM: evolutions of ctm Message-ID: <199602020831.JAA02040@sagem.fr> In-Reply-To: <v02140b00ad373cd93dcd@[199.183.109.242]> from "Richard Wackerbarth" at Feb 1, 96 10:51:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 <name>, CTM first checks for the existence > of the file <name>#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 <name>#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 <tom@smart.ruhr.de> 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 <xxxx) >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 | ---------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <199602020831.JAA02040>