diff --git a/docs/contrib/branching.md b/docs/contrib/branching.md index 06c60da9a..15d87c0d0 100644 --- a/docs/contrib/branching.md +++ b/docs/contrib/branching.md @@ -13,7 +13,7 @@ Taskwarrior and Taskserver use the same branching model. Git allows arbitrary and low-cost branching, which means that any branching model can be used. A new Git repository has one branch, the default branch, named `master`, but even this is not required. -[![master](/docs/images/master.png)](/docs/images/master.png) +[![master](master.png)](master.png) No development occurs on the `master` branch. @@ -24,7 +24,7 @@ A development branch is created from the `master` branch, and work proceeds on t Development branches are pushed to the server. Note that there are no changes on `master` - all work is done on dev branches. -[![dev](/docs/images/dev.png)](/docs/images/dev.png) +[![dev](dev.png)](dev.png) All work on dev branches is pushed to the server. @@ -36,7 +36,7 @@ This can be a useful way to manage parallel efforts on a single development mach Topic branches are also useful for merging in submitted patches, because the patch can be merged, tested and corrected independently of other efforts before being merged and pushed. A topic branch is ideal for storage of changes before an eventual merge back to the development branch. -[![topic](/docs/images/topic.png)](/docs/images/topic.png) +[![topic](topic.png)](topic.png) No topic branches are pushed to the server, they are kept local to the development machine. They are private, and therefore hidden from the server. @@ -46,7 +46,7 @@ They are private, and therefore hidden from the server. When a release is made, the development branch is merged back to the `master` branch, and a tag is applied that indicates which commit represents the release. -[![release](/docs/images/release.png)](/docs/images/release.png) +[![release](release.png)](release.png) Because only releases are merged back, the `master` branch always represent the stable release. @@ -63,7 +63,7 @@ The second branch, with the higher release number is the development branch for This is where all the work occurs. Any fix made on the development branch can be cherry-picked onto the patch branch, if necessary. -[![dev2](/docs/images/dev2.png)](/docs/images/dev2.png) +[![dev2](dev2.png)](dev2.png) To address the confusion around branching, namely determining which branch is active. the answer is that the highest numbered branch is the one that patches should be applied to. diff --git a/docs/contrib/dev.png b/docs/contrib/dev.png new file mode 100644 index 000000000..4f0b63ca6 Binary files /dev/null and b/docs/contrib/dev.png differ diff --git a/docs/contrib/dev2.png b/docs/contrib/dev2.png new file mode 100644 index 000000000..a75b1a296 Binary files /dev/null and b/docs/contrib/dev2.png differ diff --git a/docs/contrib/master.png b/docs/contrib/master.png new file mode 100644 index 000000000..a2a5cd24a Binary files /dev/null and b/docs/contrib/master.png differ diff --git a/docs/contrib/release.png b/docs/contrib/release.png new file mode 100644 index 000000000..a2a3f2346 Binary files /dev/null and b/docs/contrib/release.png differ diff --git a/docs/contrib/topic.png b/docs/contrib/topic.png new file mode 100644 index 000000000..0314c7db0 Binary files /dev/null and b/docs/contrib/topic.png differ diff --git a/docs/rfcs/protocol.md b/docs/rfcs/protocol.md index 8c13e2e71..d3d115b49 100644 --- a/docs/rfcs/protocol.md +++ b/docs/rfcs/protocol.md @@ -74,25 +74,25 @@ Each task SHALL have a 'modified' date attribute that will help resolve conflict On sync: -- Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload. +* Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload. -- Receive one of the following response codes: +* Receive one of the following response codes: - - 201: This means 'no change', and there is no further action to be taken. + * 201: This means 'no change', and there is no further action to be taken. - - 200: This means 'success', and the message payload contains a set of tasks and a sync key: + * 200: This means 'success', and the message payload contains a set of tasks and a sync key: - - The formatted tasks are to be stored as-is. + * The formatted tasks are to be stored as-is. These tasks will either be appended to the client data or will overwrite existing client data, based on the UUID of the task. No merge logic is necessary. - - The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line. + * The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line. - - 301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server. + * 301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server. - - 3xx, 4xx, 5xx: The 'status' field contains an error message. + * 3xx, 4xx, 5xx: The 'status' field contains an error message. -- If the response contained any error or warning, the error should be shown to the user. +* If the response contained any error or warning, the error should be shown to the user. This provides an opportunity for the server to announce downtime, or relocation. If no sync key is sent, the server cannot provide an incremental delta, and so will send all task data, which should be stored as above. diff --git a/docs/rfcs/week.png b/docs/rfcs/week.png deleted file mode 100644 index 49570073c..000000000 Binary files a/docs/rfcs/week.png and /dev/null differ