| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The only remaining vestiage of backends is different types of keys. These
are still called "backends", mostly to avoid needing to change user interface
and configuration. But everything to do with storing keys in different
backends was gone; instead different types of remotes are used.
In the refactoring, lots of code was moved out of odd corners like
Backend.File, to closer to where it's used, like Command.Drop and
Command.Fsck. Quite a lot of dead code was removed. Several data structures
became simpler, which may result in better runtime efficiency. There should
be no user-visible changes.
|
| |
|
|
|
| |
Just more golfing.. I am pretty sure something in a library somewhere can
do this, but I have been unable to find it.
|
| |
|
|
| |
the filename affects the key name.
|
| | |
|
| |
|
|
| |
that can be used for free space checking.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
already present in .git/annex/objects.
For example, this could happen if using SHA1 and a file with content
"foo" were added to that backend. Then a file with "content" foo were
migrated from the WORM backend.
Assume that, if a backend assigned the same key, the already annexed
content must be the same. So, the "old" content can be reused.
|
| |
|
|
|
|
|
|
| |
Free space checking is now done, for transfers of data for keys that have free space metadata.
(Notably, not for SHA* keys generated with git-annex 0.24 or earlier.)
The code is believed to work on Linux, FreeBSD, and OSX; check compile-time
messages to see if it is not enabled for your OS.
|
| |
|
|
|
| |
There are two types of commands; those that access the repository and those
that don't. Sorted.
|
| |
|
|
|
|
|
|
|
|
| |
Rename Locations functions for better consitency, and make their values
more consistent too.
Used </> rather than manually building paths. There are still more places
that manually do so, but are tricky, due to the behavior of </> when
the second FilePath is absolute. So I only changed places where
it obviously was relative.
|
| |
|
|
|
| |
This allows the Backend type to not depend on the Annex type, and
so the Annex type can later be moved out of TypeInternals.
|
| |
|
|
| |
Most of it was to do with managing annexed Content, so put there
|
| | |
|
| | |
|
|
|
backend, safely and with no duplication of content.
|
Joey Hess