More broken document links fixing

docs/build-server-support/build-server/octopus-deploy.md

@@ -1,7 +1,7 @@
 # Octopus Deploy
 While not a build server, there are a few things to consider when using Octopus Deploy with GitVersion.
 
- GitVersion follows [continuous delivery](/reference/continuous-delivery.md) versioning by default. This means builds will keep producing *the same version* with just metadata differing. For example, when you start a new release (say `1.0.0`) with git flow, the branch will start with a semver like `1.0.0-beta.1+0`, and the Octopus NuGet package will have a version of `1.0.0-beta0001`. As you commit changes to this release branch the *metadata* of the semver will increase like so: `1.0.0-beta.1+1`, `1.0.0-beta.1+2`, etc. However, the version of the corresponding Octopus NuGet package will retain the *same* `1.0.0-beta0001` version you started with. The problem is Octopus Deploy will prevent you from deploying these revisions because it sees the same NuGet package version and thinks nothing has changed.
+ GitVersion follows [continuous delivery](../../reference/continuous-delivery.md) versioning by default. This means builds will keep producing *the same version* with just metadata differing. For example, when you start a new release (say `1.0.0`) with git flow, the branch will start with a semver like `1.0.0-beta.1+0`, and the Octopus NuGet package will have a version of `1.0.0-beta0001`. As you commit changes to this release branch the *metadata* of the semver will increase like so: `1.0.0-beta.1+1`, `1.0.0-beta.1+2`, etc. However, the version of the corresponding Octopus NuGet package will retain the *same* `1.0.0-beta0001` version you started with. The problem is Octopus Deploy will prevent you from deploying these revisions because it sees the same NuGet package version and thinks nothing has changed.
 
 Because Octopus Deploy uses NuGet like this you cannot continue to push revisions in this manner without some intervention (or changes to GitVersion's configuration). To work around this problem we have two possible options:
 
@@ -34,5 +34,5 @@ The following shows an example with the corresponding git commands:
 
 This approach works well with Semantic Versioning, as you will not be burning version numbers between releases (except if a build fails to get through UAT or something, then the burnt number means something!).
 
-### Configure GitVersion to [increment per commit](/more-info/incrementing-per-commit.md)
+### Configure GitVersion to [increment per commit](../../more-info/incrementing-per-commit.md)
 As mentioned above, this means you will burn multiple versions per release. This might not be an issue for you, but can confuse consumers of your library as the version has semantic meaning.

docs/build-server-support/build-server/teamcity.md

@@ -18,7 +18,7 @@ TeamCity has support for meta-runners which allow custom tasks. There is a GitVe
 
 ## Running inside TeamCity
 * Make sure to use **agent checkouts** (required, server checkouts do not copy the needed `.git` directory)
-  - If you want to use *checkout on server*, see [dynamic repositories](/more-info/dynamic-repositories.md)
+  - If you want to use *checkout on server*, see [dynamic repositories](../../more-info/dynamic-repositories.md)
 * For the moment you need to promote the `%teamcity.build.vcs.branch.{configurationid}%` build parameter to an environment variable with the same name for pull requests to be handled correctly
 * We update the TC build number to the GitVersion number automatically
 * We output the individual values of the GitVersion version as the build parameter: `GitVersion.*` (Eg: `GitVersion.Major`) if you need access to them in your build script

docs/examples.md

@@ -27,7 +27,7 @@ This is just a small sample of the way GitVersion works. The idea is you just pl
 If you have other branch types GitVersion is entirely configuration driven, so check out the [Configuration](configuration.md) section of the readme to understand how to make GitVersion work for you.
 
 ## GitFlow
-[See GitFlow Examples](/git-branching-strategies/gitflow-examples.md)
+[See GitFlow Examples](git-branching-strategies/gitflow-examples.md)
 
 ## GitHubFlow
-[See GitHubFlow Examples](/git-branching-strategies/githubflow-examples.md)
+[See GitHubFlow Examples](git-branching-strategies/githubflow-examples.md)

docs/git-branching-strategies/gitflow-examples.md

@@ -1,5 +1,5 @@
 # GitFlow Examples
-These examples are using the *default* configuration with GitVersion. Which is [continuous deployment](/reference/continuous-deployment.md) mode for `develop` and [continuous delivery](../reference/continuous-delivery.md) mode for all other branches.
+These examples are using the *default* configuration with GitVersion. Which is [continuous deployment](../reference/continuous-deployment.md) mode for `develop` and [continuous delivery](../reference/continuous-delivery.md) mode for all other branches.
 
 This default configuration allows you to publish CI builds from develop to a CI MyGet feed, or another CI feed. Then all other branches are manually released then tagged. Read more about this at [version increments](../more-info/version-increments.md).
 

docs/git-branching-strategies/githubflow.md

@@ -3,14 +3,14 @@ GitHub Flow is a simple and effective branching strategy which the folks at GitH
 
 GitHub Flow is in a nutshell:
 
-1. Update master to latest [upstream](/reference/git-setup.md#upstream) code  
+1. Update master to latest [upstream](../reference/git-setup.md#upstream) code  
 1. Create a feature branch `git checkout -b myFeatureBranch`  
 1. Do the feature/work  
-1. Push feature branch to [origin](/reference/git-setup.md#origin)  
+1. Push feature branch to [origin](../reference/git-setup.md#origin)  
 1. Create pull request from origin/<featureBranch> -> upstream/master  
 1. Review, fix raised comments, merge your PR or even better, get someone else to.  
 
-The main rule of GitHub Flow is that master should *always* be deployable. GitHub Flow allows and encourages [continuous delivery](/reference/continuous-delivery.md).
+The main rule of GitHub Flow is that master should *always* be deployable. GitHub Flow allows and encourages [continuous delivery](../reference/continuous-delivery.md).
 
 ## Resources
  - [GitHubFlow guide by GitHub](https://guides.github.com/introduction/flow/index.html)

docs/index.md

@@ -10,7 +10,7 @@ If a commit is tagged, then GitVersion will *always* use that version over any c
 ### The Semantic Version does not increment every commit
 This trips a lot of people up, by default GitVersion *does not* increment the SemVer every commit. This means that you will get multiple builds producing the *same version* of your application.
 
-Read more at [version increments](/more-info/version-increments.md)
+Read more at [version increments](more-info/version-increments.md)
 
 ### Version sources
 There are a number of sources GitVersion can get it's versions from, they include:
@@ -21,7 +21,7 @@ There are a number of sources GitVersion can get it's versions from, they includ
  - Track version of another branch (i.e develop tracks master, so when master increments so does develop)
  - GitVersionConfig.yaml file (i.e `next-version: 2.0.0`)
 
-Read more at [version sources](/more-info/version-sources.md)
+Read more at [version sources](more-info/version-sources.md)
 
 ## Configuration
 GitVersion v3 was rewritten to be very configuration driven rather than hardcoding git workflows into it. This has made it a lot more flexible. Configuration options can be set globally or per branch.
@@ -36,4 +36,4 @@ You can just run `GitVersion.exe` in your repository to see what variables are a
 ## Exe or MSBuild Task
 There are two ways to consume GitVersion, the first is by running GitVersion.exe. The second is an MSBuild task. The MSBuild task is really easy to get up and running, simply install GitVersionTask from NuGet and it will integrate into your project and write out variables to your build server if it's running on one. The exe offers more options and works for not just .net projects.
 
-Read more about [using GitVersion](/usage/usage.md)
+Read more about [using GitVersion](usage/usage.md)

docs/more-info/how-it-works.md

@@ -1,7 +1,7 @@
 # How it works
 GitVersion v3 works very differently to v2. Version 2 had knowledge of both GitFlow and GitHubFlow hard coded into it, with each branch having it's own class which calculated the version for that branch type.
 
-v3 is driven by [configuration](/configuration.md), meaning most of the behaviors in GitVersion can be tweaked to work the way you want. It also makes it *much* more predictable and easy to diagnose why odd things are happening. 
+v3 is driven by [configuration](../configuration.md), meaning most of the behaviors in GitVersion can be tweaked to work the way you want. It also makes it *much* more predictable and easy to diagnose why odd things are happening. 
 
 ## Architecture
 GitVersion has three distict steps for calculating versions in v3.0.

docs/more-info/version-increments.md

@@ -17,7 +17,7 @@ If you are using GitFlow then builds off the `develop` branch will actually *inc
 If you need to consume packages built from develop, we recommend publishing these packages to a separate NuGet feed as an alpha channel. That way you can publish beta/release candidate builds and only people who opt into the alpha feed will see the unstable pacakges.
 
 ### 2. Octopus deploy
-See [Octopus deploy](/build-server-support/build-server/octopus-deploy.md)
+See [Octopus deploy](../build-server-support/build-server/octopus-deploy.md)
 
 ## Manually incrementing the version
 With v3 there are multiple approaches.

docs/reference/continuous-deployment.md

@@ -3,4 +3,4 @@ Continuous deployment is the process of checking into master, running all the te
 
 By default GitVersion is *not* setup to do this. The good news is in v3 of GitVersion this behavior is configurable!
 
-The default behavior for v3 and how v1 & 2 worked was that the version only incremented after a tag, which signified a release. In v3 you can simply switch the default mode in the [configuration](/configuration.md) from `continuous-delivery` to `continuous-deployment` and the version will then increment each commit, giving you the features of GitVersion with continuous deployment.
+The default behavior for v3 and how v1 & 2 worked was that the version only incremented after a tag, which signified a release. In v3 you can simply switch the default mode in the [configuration](../configuration.md) from `continuous-delivery` to `continuous-deployment` and the version will then increment each commit, giving you the features of GitVersion with continuous deployment.

docs/reference/intro-to-semver.md

@@ -24,4 +24,4 @@ For a more complete explaination checkout [semver.org](http://semver.org) which
 ## SemVer in GitVersion
 GitVersion makes it easy to follow semantic versioning in your library by automatically calculating the next semantic version which your library/application is likely to use. In GitFlow the develop branch will bump the *minor* when master is tagged, while GitHubFlow will bump the *patch*.
 
-Because one side does not always fit all, GitVersion provides many [Variables](/more-info/variables.md) for you to use which contain different variations of the version. For example SemVer will be in the format {major}.{minor}.{patch}-{tag}, but FullSemVer will also include build metadata: {major}.{minor}.{patch}-{tag}+{buildmetadata}
+Because one side does not always fit all, GitVersion provides many [Variables](../more-info/variables.md) for you to use which contain different variations of the version. For example SemVer will be in the format {major}.{minor}.{patch}-{tag}, but FullSemVer will also include build metadata: {major}.{minor}.{patch}-{tag}+{buildmetadata}

docs/reference/mainline-development.md

@@ -1,5 +1,5 @@
 # Mainline development
-Mainline development is enabled when using [GitHubFlow](/git-branching-strategies/githubflow.md) or any other strategy where you develop on `master`. The main rule of mainline development is that **master is always in a state that it could be deployed to production**. This means that pull requests should not be merged until they are ready to go out.
+Mainline development is enabled when using [GitHubFlow](../git-branching-strategies/githubflow.md) or any other strategy where you develop on `master`. The main rule of mainline development is that **master is always in a state that it could be deployed to production**. This means that pull requests should not be merged until they are ready to go out.
 
 To properly achieve mainline development you need confidence in your test suite as if it goes green against a PR then you are confident that you can merge and release that pull request. Another property of mainline development is normally that you fix going forward, not revert. When an issue is discovered with a release, add a test or some sort of check to make sure it won't happen again, fix the issue, then do a release with the fix.
 

docs/usage/command-line.md

@@ -10,9 +10,9 @@ Switches are available with `GitVersion /?`
 
 ## Output
 
-By default GitVersion returns a json object to stdout containing all the [variables](/more-info/variables.md) which GitVersion generates. This works great if you want to get your build scripts to parse the json object then use the variables, but there is a simpler way.
+By default GitVersion returns a json object to stdout containing all the [variables](../more-info/variables.md) which GitVersion generates. This works great if you want to get your build scripts to parse the json object then use the variables, but there is a simpler way.
 
-`GitVersion.exe /output buildserver` will change the mode of GitVersion to write out the variables to whatever build server it is running in. You can then use those variables in your build scripts or run different tools to create versioned NuGet packages or whatever you would like to do. See [build servers](/build-server-support/build-server-support.md) for more information about this.
+`GitVersion.exe /output buildserver` will change the mode of GitVersion to write out the variables to whatever build server it is running in. You can then use those variables in your build scripts or run different tools to create versioned NuGet packages or whatever you would like to do. See [build servers](../build-server-support/build-server-support.md) for more information about this.
 
 ## Inject version metadata into the assembly
 `GitVersion.exe /updateassemblyinfo` will recursively search for all `AssemblyInfo.cs` files in the git repo and update them. 

docs/usage/msbuild-task.md

@@ -28,7 +28,7 @@ Now when you build:
 
 ### Other injected Variables
 
-All other [variables](/more-info/variables.md) will be injected into a internal static class.
+All other [variables](../more-info/variables.md) will be injected into a internal static class.
 
 ```
 namespace AssemblyName
@@ -72,7 +72,7 @@ Trace.WriteLine(versionField.GetValue(null));
 
 Task Name: `GitVersionTask.GetVersion`
 
-At build time all the derived [variables](/more-info/variables.md) will be written to MSBuild properties so the information can be used by other tooling in the build pipeline.
+At build time all the derived [variables](../more-info/variables.md) will be written to MSBuild properties so the information can be used by other tooling in the build pipeline.
 
 The class for `GitVersionTask.GetVersion` has a property for each variable. However at MSBuild time these properties a mapped to MSBuild properties that are prefixed with `GitVersion_`. This prevents conflicts with other properties in the pipeline.
 
@@ -86,7 +86,7 @@ After `GitVersionTask.GetVersion` has executed the properties can be used in the
 
 Task Name: `GitVersionTask.WriteVersionInfoToBuildLog`
 
-If, at build time, it is detected that the build is occurring inside a Build Server server then the [variables](/more-info/variables.md) will be written to the build log in a format that the current Build Server can consume. See [Build Server Support](/build-server-support/build-server-support.md).
+If, at build time, it is detected that the build is occurring inside a Build Server server then the [variables](../more-info/variables.md) will be written to the build log in a format that the current Build Server can consume. See [Build Server Support](../build-server-support/build-server-support.md).
 
 ## My Git repository requires authentication. What do I do?
 

docs/usage/usage.md

@@ -9,4 +9,4 @@ There are two main ways to consume GitVersion, the first is by running GitVersio
  - [Using the Ruby Gem](gem.md)
 
 
- There exist also wrappers around the [Command Line tool](command-line.md) for several build servers. See [Build server support](/build-server-support/build-server-support.md) for details. 
+ There exist also wrappers around the [Command Line tool](command-line.md) for several build servers. See [Build server support](../build-server-support/build-server-support.md) for details.