| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resuming after the last successfully uploaded chunk.
"checkPresent baser" was wrong; the baser has a dummy checkPresent action
not the real one. So, to fix this, we need to call preparecheckpresent to
get a checkpresent action that can be used to check if chunks are present.
Note that, for remotes like S3, this means that the preparer is run,
which opens a S3 handle, that will be used for each checkpresent of a
chunk. That's a good thing; if we're resuming an upload that's already many
chunks in, it'll reuse that same http connection for each chunk it checks.
Still, it's not a perfectly ideal thing, since this is a different http
connection that the one that will be used to upload chunks. It would be
nice to improve the API so that both use the same http connection.
|
| |
|
|
|
|
| |
includes bash completion.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
Debian stable has 0.10.0.
|
|
|
|
|
|
| |
This provides a way to not consider old versions of files to be unused after they have reached a specified age, when the old refs in the reflog expire.
May be slow.
|
|
|
|
| |
while still merging with remote to the extent possible.
|
|
|
|
| |
to annexed content.
|
|
|
|
|
|
| |
The branch needs to be created when merging from the remote in sync,
since we diff between it and the remote's sync branch. But git annex merge
should not be creating sync branches.
|
|
|
|
|
| |
As well as import, 2 other places ran "mv" manually, so changed them to use
moveFile as well.
|
| |
|
|
|
|
| |
libraries including libyaml.
|
|
|
|
| |
equivilant to "world".
|
|
|
|
| |
the git-annex branch, so it works when run in a subdirectory. This bug affected git-annex unused, and potentially also transitions running code and other things.
|
|
|
|
| |
found a use case for it. Note that the command's syntax was changed for consistency.
|
|
|
|
|
|
|
|
|
|
| |
pairing to be the absolute path to the repository, not "."
This was a reversion caused by the relative path changes in 5.20150113.
Other uses of addAuthorizedKeys seem to be ok. If the user enters a
directory like ~/annex, it writes GIT_ANNEX_SHELL_DIRECTORY=annex, and
git-annex-shell assumes that's relative to HOME.
|
|
|
|
| |
rejected on the other end for security reasons.
|
|
|
|
| |
might be left over from a previous login session and so unable to use the ssh agent of a new login session.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes git annex unused use around 48 mb more memory than it did before,
but the massive increase in accuracy makes this worthwhile for all but the
smallest systems.
Also, I want to use the bloom filter for sync --all --content, to avoid
dropping files that the preferred content doesn't want, and 1/1000
false positives would be far too many in that use case, even if it were
acceptable for unused.
Actual memory use numbers:
1000: 21.06user 3.42system 0:26.40elapsed 92%CPU (0avgtext+0avgdata 501552maxresident)k
1000000: 21.41user 3.55system 0:26.84elapsed 93%CPU (0avgtext+0avgdata 549496maxresident)k
10000000: 21.84user 3.52system 0:27.89elapsed 90%CPU (0avgtext+0avgdata 549920maxresident)k
Based on these numbers, 10 million seemed a better pick than 1 million.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--content
backup: Use new "anything" terminal. This means that content that
is not unused, but has no associated file will be wanted by backup repos.
unwanted: "not anything" will result in any and all content moving
off of these repos.
incremental backup: Remove the "(include=* or unused)",
so it matches content that has no associated files
but is not unused.
client: Add a include=* to the expression. This limits it to matching
only files in the work tree. Without this change, sync --all --content
would match a key against the expression, and since it matches
exclude=archive/*, the client repo would have wanted the file content.
The "and not unused" would have kept unused objects out, but not
objects that were not known to be unused, or objects that another branch
referred to. In practice, everything would have flooded into client repos
without this change.
|
|
|
|
|
|
| |
documentation, which says it does not want files that have reached a backup repository.
Checked history and these have been out of sync from the very beginning!
|
|
|
|
| |
versions of all files.
|
| |
|
|
|
|
| |
"repositories containing these files", and "transfers in progress".
|
| |
|
| |
|
|
|
|
|
|
| |
their paths.
Ie, "https://archive.org/download/zoom-2/Zoom - Release 2 (1996)(Active Software)[!].iso"
|
|
|
|
|
|
|
|
| |
with annex.tune.objecthash1=true
Need to walk 1 level of subdirs less in this case.
The git-annex branch traversal code didn't have a similar bug.
|
| |
|
|
|
|
| |
ikiwiki feature.) Closes: #785736
|
|
|
|
| |
versions of tahoe create-client choking.
|
| |
|
| |
|
| |
|
|
|
|
| |
in a bare repo. Otherwise, still reports files with lost contents, even if the content is dead.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In my tests, this has to be set when uploading a file to the bucket
and then the file can be accessed using the bucketname.s3.amazonaws.com
url.
Setting it when creating the bucket didn't seem to make the whole bucket
public, or allow accessing files stored in it. But I have gone ahead and
also sent it when creating the bucket just in case that is needed in some
case.
|
|
|
|
| |
copy of a file as one of the necessary copies to allow removing it from the import location.
|