Feature set to show the list of snapshots and their respective size.

For both stash and remote.

This, on the face of it, seems complex due to the need to interact with WP-CLI, WP Database, and Git.

• Declare a Fact trait which we can use as an interface between a project and WP-CLI + Git. This could solve the problem of setting up a full WP environment.
• Build a module to build separate test contexts to include a SPROUT_HOME and local repo
• Provide fake WordPress uploads content to snapshot

sprout snap my-branch appears to push to the previously set branch, not the new one.

• on main
• sprout snap my-branch creates snapshot for main
• sprout snap my-other-branch creates snapshot for my-branch
• sprout snap main creates snapshot for my-other-branch

• Optionally label a snapshot with text.
• Optionally save a description.
• Show label in ls table
• Create a new command to show snapshot information sprout describe <id>, including description

The docs are lacking at the moment! This issue tracks all of the things we'd like to include.

• reference: internals (sprt_ tagging, uniqueness digest, branch parents)
• guide: repo management / maintenance
• guide: stashes
• guide: branching
• reference: sprout.yaml format
• guide: using onedrive
• guide: using dropbox
• guide: using google drive
• guide: using restic http server
• guide: sftp

• Clap inline docs - review
• docs: installation instructions
• readme: point to proper docs
• guide: S3
• guide: Setting up a repo
• guide: Snapshotting a project
• guide: Using branches
• guide: Seeding from a snapshot
• guide: Environment vars in repo definition
• docs: how to use / what is it

Allow usage of environment variables in repo definitions.

Eg.

access_key: ${MY_ACCESS_KEY}

Currently all remote repo information is stored in a project's sprout.yaml. This isn't great, as we may want to have credentials for cloud storage set up as part of repository's options object.

This feature will address the shortcoming by implementing:

• Individual repository configs stored in ~/.sprout/repos
• Support env var expansion in ~/.sprout/repos/<repo-label>.yaml
• sprout.yaml should only refer to the repo by label

Command Changes

• sprout repo list - List all available repos
• sprout repo new - Create new repo file and open default editor
• sprout repo get <repo-label> - Return repo information for <repo-label>
• sprout repo init should be changed to require a repo-label not a path

Hey there,
as you are an early user of rustic_core, we would like to understand better how the API of rustic_core fares you. Do you have any feedback, do you miss anything? :-)

To reduce friction when initialising a new project, we could attempt to determine the correct wp-uploads path instead of a dumb default.

All of the logic is present and written, but cold on main.

If wp core is-installed fails, we just warn and revert to the default path.

This issue serves as a planning scratchpad to bring Sprout up to a stable 1.0.0 release.

<0.1.1: For next pre-release

???

<1.0.0: For stable

• #19
• build: windows
• feature: installer for windows

Backlog / Ideas(?)

• feature?: repo access token management
• feature?: share repo definitions
• feature?: punch-in for user passwords
• feature?: DB anonymisation - out of scope

Wider discussion

Although I made this for WordPress, there's no reason why this approach wouldn't work for other software projects that depend on large content storage.

There are some specialisations for WordPress (DB search replace on site URL for example) that would need to be abstracted away. Other types of project would likely have similar specifics.

Is it worth planning to turn Sprout into a general content seeding and storage tool?

And if so, at what point do we do that?

To fix the linux-aarch64-musl build, a patch was applied to zstd-sys.

PR for fix is open. gyscos/zstd-rs#262

Revert the cargo.toml patch for zstd-sys once this is released.