<h3><aid="usernamepassword">Getting a username and password</a></h3>
<p>Use these credentials for access to the site. The user is 'expo',
with a cavey:beery password. Ask someone if this isn't enough clue for you.
<b>This password is important for security</b>. The whole site <strong>will</strong> get hacked by spammers or worse if you are not careful with it. Use a secure method for passing it on to others that need to know (i.e not unencrypted email), don't publish it anywhere, don't check it in to the data management system by accident. A lot of people use it and changing it is a pain for everyone so do take a bit of care.
</p>
<p>Note that you don't need a password to view most things, but you will need one to change them</p>
<p>This password is all you need to log in to troggle and to use the control panel. But if you want to edit the software itself, or update webpages, then
you will also need to get a cryptographic key and register it with the server. See <ahref="computing/keyexchange.html">key exchange</a> for details.
<p>Unfortunately, pushing cave data to ::loser:: and ::drawings:: also needs a key. So cavers entering their cave survey data
currently have to use a machine on which this already set up. These machines are
the <i>expo laptop</i> and the laptop '<i>aziaphale</i>' which live in the potato hut during expo.
<li><ahref="http://expo.survex.com/cgit/troggle/.git/log">troggle</a> - the database/software part of the survey data management system - see <ahref="troggle-ish.html">notes on troggle</a> for further explanation</li>
<p>(do be <b>incredibly</b> careful not to delete piles of stuff then rsync back, or to get the directory level of the command wrong - as it'll all get deleted on the server too, and we may not have backups!). It's <b>absolutely vital</b>Use rsync --dry-run --delete-after -a first to check what would be deleted.
<p>If you are using rsync from a Windows machine you will <em>not</em> get all the files as some filenames are incompatible with Windows. What will happen is that rsync will invisibly change the names as it downloads them from the Linux expo server to your Windows machine, but then it forgets what it has done and tries to re-upload all the renamed files to the server even if you have touched none of them. Now there won't be any problems with simple filenames using all lowercase letters and no funny characters, but we have nothing in place to stop anyone creating such a filename somewhere in that 60GB or of detecting the problem at the time. So don't do it. If you have a Windows machine use Filezilla not rsync.
<p>(We may also have an issue with rsync not using the appropriate user:group attributes for files pushed back to the server. This may not cause any problems, but watch out for it.)</p>
</dl>
<h3><aid="editingthedata management system">Editing the data management system</a></h3>
<p>The commit has stored the changes in your local Mercurial DVCS, but it has not sent anything back to the server. To do that you need to:</p>
<p><tt>hg push</tt></p>
<p>Before pushing, you should do an <tt>hg pull</tt> to sync with upstream first. If someone else has edited the same files you may also need to do:</p>
<p><tt>hg merge</tt></p>
<p>(and sort out any conflicts if you've both edited the same file) before pushing again</p>
<p>Simple changes to static files will take effect immediately, but changes to dynamically-generated files (cave descriptions, QM lists etc) will not take effect, until the server runs the expoweb-update script.</p>
<p>The script at the heart of the data management system update mechanism is a makefile that runs the various generation scripts. It is run every 15 minutes as a cron job (at 0,15,30 and 45 past the hour), but if you want to force an update more quickly you can run it he</p>
<p>The scripts are generally under the 'noinfo' section of the site just because that has (had) some access control. This will get changed to something more sensible at some point</p>
<h3><aid="cavepages">Updating cave pages</a></h3>
<p>Cave description pages are automatically generated from a set of
cave files in noinfo/cave_data/ and noinfo/entrance_data/. These files
are named <area>-<cavenumber>.html (where area is 1623 or 1626). These
files are processed by troggle. Use <tt>python databaseReset.py
caves</tt> in /expofiles/troggle/ to update the site/database after
editing these files.</p>
<p>Clicking on 'New cave' (at the bottom of the cave index) lets you enter a new cave. <ahref="caveentry.html">Info on how to enter new caves has been split into its own page</a>.</p>
<p>(If you remember something about CAVETAB2.CSV for editing caves, that was
superseded in 2012).</p>
<p>This may be a useful reminder of what is in a survex file <ahref="survey/how_to_make_a_survex_file.pdf">how to create a survex file</a>.
<h3><aid="updatingyears">Updating expo year pages</a></h3>
<p>Each year's expo has a documentation index which is in the folder</p>
<p>/expoweb/years</tt></p>
<p>, so to checkout the 2011 page, for example, you would use</p>
<p> Once you have pushed your changes to the repository you need to update the server's local copies, by ssh into the server and running hg update in the expoweb folder. </p>
