dnh wrote: > > Could someone please send an email explaining exactly; > > a) how one 'collects arches' > b) when one should 'collect arches' > c) what to avoid when 'collecting arches' > d) the reason for 'collecting arches' Note: I use 'you' a lot in the message below, but this meant as a general term, and not you as in darth bob. Requirements to collect the archetypes: 1) Have a copy of the server installed on your system. 2) In the lib directory of the server source, have the 'arch' directory available. Available here means that either this is the location of the arch distribution (ie, where you unpacked it), or is a symlink (ln -s ... ...) to where you have unpacked/cvs checkout the arch directory. To answer your questions: a) From the lib directory described above, type 'rm archetypes; make'. This should do the right thing. b) Simple answer is anytime you change entries in the arch tree, you need to collect them and then install them to take effect. In terms of CVS, whenever changes are made to the arch tree, after the changes are verified to work, you should collect the archs and check them into CVS (so for example, remote sites only need to checkout/update the server, and not have to check out the arch's and rebuild for their own seerver. Note that collecting the archs does not mean your local server (or in the case of a cvs update) will necessarily use them. You still need to do a make install for the arch's (and images) to get copied to where the server expects to find them. The one exception to this case is if you have set up your crossfire installation such that the install directory is the same as your working directory. c) Bugs. As with all checkins to CVS, it should be verified there are no bugs in the built archs. This is hard to test 100%, as the definition of a bug can very (ie, if some monster is worth too much exp, that may be a bug, but not really the type I am thinkg of here). What I am thinking of here are things like typos, bad reference to other items (ie, randomitems, other_arch, face, ...). Most of the last case will be caught by crossfire when it runs, so watch the output of the server at startup to see if it complains about missing archs/faces or other things. Note that a collect of the arch and testing as described above should be done even when just changing the the individual .arc file. After all, some servers may have added their custom archs, and hence rebuild them on a regular basis, so checking in a bad .arc file will still mess them up, even if you haven't checked in a collected version. Or similarly, perhaps someone else has done a cvs update of their arch directory and grabbed your changes, and made some other changes they are committing, and do run the collect process - even though their arc's may be find, your arch's would still cause problems in the collected version. Also, if you are collecting and checking in images, make sure you don't collect the alternate image set and check those in (crossfire.png). this will happen if you have a alternate_image directory/symlink in your lib directory that contains images. d) see answeer to b above. Basically, if you don't collect them, someone will have to at some point in order to use them. the arch tree is not used at all by the server - its existance is to make editing and find files easier. Now this doesn't need to be done for every change you make. For example, if you change 5 things, and you know you are going to change 5 more things tomorrow, you could just wait until then to run the collect. But then by the same token, you should probably wait until then before you run a commit in the arch directory, and commit all 10 at the same time. Now it would be possible for someone to set up a cron job that does an make collect each night, and if any of the relevant files are different, automatically commit them. In this case, when you make a change to the arch directory, youu wouldn't need to run the collect - the nightly collect process would do that for you (and all other developers). OTOH, the creation of such a script is more than just a make collect, cvs commit - some sanity checking should also be done to make sure that make collect did not have errors, that the output files are in fact intact (and not truncated for any of a variety of reasons), etc.