48 lines
2.4 KiB
Markdown
48 lines
2.4 KiB
Markdown
## Unclear Functionality Questions
|
|
|
|
7. **Version semantics:**
|
|
- What is relationship between `branch_name` and `version`?
|
|
we're making `git symbolic-ref --short HEAD` to inspect current branch before version sync and add current branch to the existed one on the server this field if the branch was changes.
|
|
it's just a visual strings to identify on which git branches this version was used, so it's easier to the user to decide what version's is needed;
|
|
while merge operation user's current branch overrides version's branch with an interactive prompt, that lets user to use current one or write a string with a custom one
|
|
|
|
8. **Sync behavior:**
|
|
- "if version is inactive, server responds w/ latest version data" — what if NO active version exists?
|
|
Answer: provide some variants
|
|
|
|
- "recursively asks what environments to save" — what's the UX flow here? Interactive prompts?
|
|
Answer: interactive prompts, f.e.:
|
|
```
|
|
ENVIRONMENT NAME:
|
|
VARIABLE NAME:
|
|
version timestamp 1: -
|
|
version timestamp 2: WABALABUDABDAB
|
|
version timestamp 3: BABRAKADABRA
|
|
please enter the number of the valid VAR for a new version;
|
|
```
|
|
|
|
9. **Merge behavior:**
|
|
- What happens to source versions after merge? Deleted? Marked inactive?
|
|
Answer: source versions should be marked as inactive and cannot be updated anymore;
|
|
|
|
- `-v, --version` takes "list of versions" — what format? Comma-separated? Multiple flags?
|
|
Answer: just space separated list of version's timestamps;
|
|
|
|
10. **Config scope:**
|
|
- Is `api_key` per-project or can it be global (e.g., in `~/.config/aevs/`)?
|
|
Answer: `api_key`'s scope is a user's scope; user management would be implemented later
|
|
|
|
- Can config inherit from parent directories?
|
|
Answer: do not understand the question;
|
|
|
|
---
|
|
|
|
## Missing Information
|
|
|
|
11. **Error handling:** What happens on network failure during sync/merge?
|
|
Answer: failing error w/ the previous state of the entities;
|
|
12. **Authentication:** How is api_key validated? What permissions does it grant?
|
|
Answer: for now let api_key be a hardcoded value, we'd create web server later;
|
|
13. **Conflict resolution:** In sync, what if local and remote have conflicting changes?
|
|
Answer: We've previously discussed merging conflicts flow. If it's not a merge operation we're going through a conflict resolution flow, but there'd be new version created as local, as at the server;
|