This crate has been moved to
https://github.com/GothenburgBitFactory/taskchampion-sync-server.
The integration-tests repo used the sync server to test integration
between taskchampion and the sync-server. We should do that again, but
after taskchampion moves to its own repo (#3209). In the interim, the
cross-sync integration test can simply test syncing between local
servers, but the snapshot test is no longer useful as the local server
does not support snapshots.
* Recommend LSP's in development docs
Per conversation in #3338.
There are already a lot of documented compile options so I think we're
better off suggesting that everybody create a compile_commands.json
whether or not they're using an LSP because it doesn't cost much.
While I was at it it seemed reasonable to mention rust LSP too. Now that
rls is deprecated I'm not sure there is any competitor to rust-analyzer
worth mentioning.
* Export compile commands by default.
Thanks to @felixschurk for the idea and telling me how to do it.
It took me a minute to figure out that this places the
compile_commands.json in the build directory rather than the root of the
project. But clangd still finds it there and that's a better place for
it anyway.
* update build instructions
Usage of "modern" CMake syntax and using specific out of source build.
Further add example on how to build in parallel, build a specific target
and how to change the compiler.
This closes#3236.
* Add support for cloud sync, specifically GCP
This adds generic support for sync to cloud services, with specific
spuport for GCP. Adding others -- so long as they support a
compare-and-set operation -- should be comparatively straightforward.
The cloud support includes cleanup of unnecessary data, and should keep
total space usage roughly proportional to the number of tasks.
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
* move doc/misc to top level, add READMEs
* Move docs -> doc/devel
This also consolidates the _three_ documents describing (differently)
how to build Taskwarrior into a signle document.
In #3118 @ryneeverett mentioned that "key" suggests that this is a
secret, when in truth it's just a user identifier. So "ID" is a better
word for it than "key".
This removes use of gnutls and the TLS implementation, which is no
longer needed (task synchronization is handled via Taskchampion, which
uses `reqwest`, which handles TLS via other Rust dependencies). This
incidentally removes the following config options:
* `debug.tls`
* `taskd.ca`
* `taskd.certificate`
* `taskd.ciphers`
* `taskd.credentials`
* `taskd.key`
* `taskd.server`
* `taskd.trust`
The simple fact that the task has a single or more tags of any value
does not convey a lot of information. As such, we should not color tasks
based on this property by default.
Users can still configure the color.tagged configuration variable if the
color rule makes sense in their system.
This also drops support for the transitional `json.depends.array`
configuration value, which has not been necessary since ~2016.
As with tags, dependencies are stored in both a "combined",
comma-separated format (for compatibility) and in an
attribute-per-dependency format (for the future).
Every configuration parameter can be overwritten for the
current context by setting the parameter:
context.<name>.rc.<parameter> = <value>
in the config file. This allows for example to set a custom
report for each context.
