diff options
Diffstat (limited to 'doc/devblog/day_248__workload_tuning.mdwn')
| -rw-r--r-- | doc/devblog/day_248__workload_tuning.mdwn | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/devblog/day_248__workload_tuning.mdwn b/doc/devblog/day_248__workload_tuning.mdwn index d1fee2926..d0677fc60 100644 --- a/doc/devblog/day_248__workload_tuning.mdwn +++ b/doc/devblog/day_248__workload_tuning.mdwn @@ -8,7 +8,7 @@ Today I put together a lot of things I've been thinking about: git-annex user to upgrade their repository, and would be very painful. It's hard to imagine a change that is worth that amount of pain. * There are other changes some would like to see (like lower-case object - hash directory names) that are certianly not enough to warrant a flag + hash directory names) that are certainly not enough to warrant a flag day repo format upgrade. * It would be nice to let people who want to have some flexibility to play around with changes, in their own repos, as long as they don't a) @@ -32,7 +32,7 @@ The main limitations are: I built all the infrastructure for this today. Basically, the git-annex branch gets a record of all tunings that have been applied, and they're -automatically propigated to new clones of a repository. +automatically propagated to new clones of a repository. And I implemented the first tunable setting: @@ -40,10 +40,10 @@ And I implemented the first tunable setting: This is definitely an experimental feature for now. `git-annex merge` and similar commands will detect attempts to merge -between incompatably tuned repositories, and error out. But, there are a +between incompatibly tuned repositories, and error out. But, there are a lot of ways to shoot yourself in the foot if you use this feature: -* Nothing stops `git merge` from merging two incompatable repositories. +* Nothing stops `git merge` from merging two incompatible repositories. * Nothing stops any version of git-annex older from today from merging either. |