mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

rename v6 design page

Browse source
This commit is contained in:
Joey Hess 2016-02-09 12:34:58 -04:00
parent edc5829785
commit d3666228ee
Failed to extract signature
3 changed files with 8 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/design/v6.mdwn → doc/design/new_repo_versions.mdwn
View file

@ -1,7 +1,7 @@
This page's purpose is to collect and explore plans for a future This page's purpose is to collect and explore plans for a future
annex.version 6. annex.version.
There are two major possible changes that could go in v6 or a later There are two major possible changes that could go in a new repo
version that would require a hard migration of git-annex repositories: version that would require a hard migration of git-annex repositories:
1. Changing .git/annex/objects/ paths, as appear in the git-annex symlinks. 1. Changing .git/annex/objects/ paths, as appear in the git-annex symlinks.
@ -115,7 +115,7 @@ Possible reasons to make changes:
## living on the edge ## living on the edge
Rather than a hard transition, git-annex could add a v6 mode Rather than a hard transition, git-annex could add a mode
that could be optionally enabled when initing a repo for the first time. that could be optionally enabled when initing a repo for the first time.
Users who know they need that mode could then turn it one, and get the Users who know they need that mode could then turn it one, and get the
@ -126,14 +126,14 @@ There could even be multiple modes, with different tradeoffs depending on
how the repo will be used, its size, etc. Of course that adds complexity. how the repo will be used, its size, etc. Of course that adds complexity.
But the main problem with this idea is, how to avoid the foot shooting But the main problem with this idea is, how to avoid the foot shooting
result of merging repo A(v5) into repo B(v6)? This seems like it would be result of merging repo A(v5) into repo B(vNG)? This seems like it would be
all to easy for a user to do. all to easy for a user to do.
As far as git-annex branch changes go, it might be possible for git-annex As far as git-annex branch changes go, it might be possible for git-annex
to paper over the problem by handling both versions in the merged git-annex to paper over the problem by handling both versions in the merged git-annex
branch, as discussed earlier. But for .git/annex/objects/ changes, there branch, as discussed earlier. But for .git/annex/objects/ changes, there
does not seem to be a reasonable thing for git-annex to do. When it's does not seem to be a reasonable thing for git-annex to do. When it's
receiving an object into a mixed v5 and v6 repo, it can't know which receiving an object into a mixed v5 and vNG repo, it can't know which
location that repo expects the object file to be located in. Different location that repo expects the object file to be located in. Different
files in the repo might point to the same object in different locations! files in the repo might point to the same object in different locations!
Total mess. Must avoid this. Total mess. Must avoid this.
@ -180,7 +180,7 @@ they want to make the default meet their use case better, that is more
a matter of configuration than of picking a version. a matter of configuration than of picking a version.
For example, we could say that the user is opting out of the second-level For example, we could say that the user is opting out of the second-level
object hash directories. Or we could say the user is choosing to use v6, object hash directories. Or we could say the user is choosing to use vNG,
which is like v5 except with different object hash directory structure. which is like v5 except with different object hash directory structure.
git annex init --config annex.objects.hashdirectories 1 git annex init --config annex.objects.hashdirectories 1

2
doc/design/roadmap.mdwn
View file

@ -6,7 +6,7 @@
* [[assistant/gpgkeys]] management for the assistant * [[assistant/gpgkeys]] management for the assistant
* [[assistant/telehash]] or similar * [[assistant/telehash]] or similar
* [[design/requests_routing]] * [[design/requests_routing]]
* [[design/v6]] repo format * [[design/new_repo_versions]]
## the rearview ## the rearview

2
doc/devblog/day_248__workload_tuning.mdwn
View file

@ -15,7 +15,7 @@ Today I put together a lot of things I've been thinking about:
make git-annex a lot more complicated, or b) negatively impact others. make git-annex a lot more complicated, or b) negatively impact others.
(Without having to fork git-annex.) (Without having to fork git-annex.)
This is discussed in more depth in [[design/v6]]. This is discussed in more depth in [[design/new_repo_versions]].
The solution, which I've built today, is support for The solution, which I've built today, is support for
[[tuning]] settings, when a new repository is first created. The resulting [[tuning]] settings, when a new repository is first created. The resulting