Correct typos

Author: Tom-Willemsen

doc/iocs/compiling/Developer-Updating.md

@@ -2,7 +2,7 @@
 
 ## using a pre-built distribution
 
-If you just want a clean start then you can use a pre-built build server checkout [[Developer-Server-Build]] as a new starting point. This is by far the easiest - it is the equivalent of deleting your current EPICS directory, doing a clean checkout and then building, just a bit quicker as it has already been built/compiled for you on the build server. If you have no important local changes (i.e. everything is pushed to github) then you will lose nothing and can just swap back to these branches after the new install.
+If you just want a clean start then you can use a [pre-built build server checkout](/iocs/compiling/Developer-Server-Build) as a new starting point. This is by far the easiest - it is the equivalent of deleting your current EPICS directory, doing a clean checkout and then building, just a bit quicker as it has already been built/compiled for you on the build server. If you have no important local changes (i.e. everything is pushed to github) then you will lose nothing and can just swap back to these branches after the new install.
 
 ## updating in-place
 
@@ -51,7 +51,7 @@ git submodule foreach --recursive "git reset --hard"
 git submodule foreach --recursive "git clean -fdx"
 ```
 
-Now build IBEX in the usual way. See [[Things-to-know-as-a-developer]] for speeding up a build.
+Now build IBEX in the usual way. See [here](/processes/dev_processes/Things-to-know-as-a-developer) for speeding up a build.
 
 ### Troubleshooting
 

doc/iocs/creation/Creating-IOC-wrapper-VI.md

@@ -59,7 +59,7 @@ endif
 
 ## 2. Create the xml configuration file
 
-This is a summary of [[more general LvDCOM instructions|http://epics.isis.stfc.ac.uk/doxygen/lvDCOM]].
+This is a summary of [more general LvDCOM instructions](http://epics.isis.stfc.ac.uk/doxygen/lvDCOM).
 
 1. Open the VI in lab view.
 1. Export strings from the LabVIEW panel (In different version of LabVIEW this is different)

doc/processes/git_and_github/Git-workflow.md

@@ -72,7 +72,7 @@ NOTE: if you run `git config --global push.recurseSubmodules check` once, then t
 
 ## Updating all Submodules
 
-If you want a clean start then you can use a [[Developer-Server-Build]] rather than an in place git update
+If you want a clean start then you can use a [Developer-Server-Build](/iocs/compiling/Developer-Server-Build) rather than an in place git update
 
 The following command used to be used in the project I leave it here for the minute. I believe that when run from the EPICS directory it updates all submodules by merging in the last commit from origin. This feels like you could have problems if your submodule is on a different branch
 

doc/specific_iocs/motors/galil/Updating-old-galil-driver.md

@@ -1,12 +1,12 @@
 # Updating the old Galil driver
 
-As described in [[New Galil Driver]] The OLD galil driver is build from a galil-old top level EPICS branch on ndhspare53, this is because it needs to be compiled with Visual Studio 2010. This build is then copied on a release to provide support/galil-old and  ioc/master/GALIL-OLD directories. A top level swap_galil.bat script is provided which swaps GALIL and GALIL-OLD, also when the release git repository is created a galil-old release files branch is created that matches the swapped branch.  
+As described in [new Galil driver](New-Galil-Driver), the OLD Galil driver is build from a `galil-old` top level EPICS branch on ndhspare53, this is because it needs to be compiled with Visual Studio 2010. This build is then copied on a release to provide `support/galil-old` and `ioc/master/GALIL-OLD` directories. A top level `swap_galil.bat` script is provided which swaps `GALIL` and `GALIL-OLD`, also when the release git repository is created a `galil-old` release files branch is created that matches the swapped branch.  
 
-The galil-old structures needs to be kept in step to some extent with the main master tree, however some care is needed as not all changes are relevant, and because of the need to compile with VS2010 not all changes are possible to integrate e.g. a third party dependency like mysql may need a higher compiler version. Also not that we are replacing just one IOC of a main distribution, so we don;t need every change on galil-old just those relevant to building this ioc.    
+The `galil-old` structures needs to be kept in step to some extent with the main master tree, however some care is needed as not all changes are relevant, and because of the need to compile with VS2010 not all changes are possible to integrate e.g. a third party dependency like MySQL may need a higher compiler version. Also not that we are replacing just one IOC of a main distribution, so we don't need every change on `galil-old`, just those relevant to building this ioc.    
 
-Currently explicit galil-old branches exist for EPICS top, support/galil and ioc/master - other modules have just have pinned versions to EPICS that may not be the most recent (e.g. because newer versions do not compile with VS2010). Updating the to level galil-old EPICS branch should consider the following.
-- if a change is made to support/galil master branch of EPICS-galil repository consider if this needs back-porting to the galil-old branch of this repository
-- if a change is made to ioc/master/GALIL or ioc/master/GALILMUL consider if it needs back-porting to galil-old branch of this repository
-- some support modules get built into the galil ioc so the galil-old EPICS top level needs to be pinned to the most recent version of these e.g. sampleChanger, motionSetpoints. In general it is not a problem (but not necessary) to have all submodule repositories that are not on a separate galil-old branch to be at the most recent version, however in some cases this is not possible due to compiler conflicts
+Currently explicit `galil-old` branches exist for EPICS top, `support/galil` and `ioc/master` - other modules have just have pinned versions to EPICS that may not be the most recent (e.g. because newer versions do not compile with VS2010). Updating the top level `galil-old` EPICS branch should consider the following.
+- If a change is made to `support/galil` master branch of EPICS-galil repository consider if this needs back-porting to the `galil-old` branch of this repository
+- If a change is made to `ioc/master/GALIL` or `ioc/master/GALILMUL` consider if it needs back-porting to `galil-old` branch of this repository
+- Some support modules get built into the galil ioc so the `galil-old` EPICS top level needs to be pinned to the most recent version of these e.g. sampleChanger, motionSetpoints. In general it is not a problem (but not necessary) to have all submodule repositories that are not on a separate `galil-old` branch to be at the most recent version, however in some cases this is not possible due to compiler conflicts