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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2016-09-26 16:49:21 -04:00
commit f3b84f4603
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
7 changed files with 208 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn Normal file
View file

@ -0,0 +1,90 @@
### Please describe the problem.
When using the assistant to synchronize several annex repositories, changes are not correctly or not at all propagated to repositories that are in the adjusted branch.
* New files from other repositories are not created automatically in adjusted branch repos
* Commited changes in files from other repositories are not reflected in in adjusted branch repos
The manual states:
> To propigate changes from the adjusted branch back to the original
> branch, and to other repositories, as well as to merge in changes from
> other repositories, use git annex sync.
I would expect that the assistant is just doing this, that I don't have to trigger the sync in the adjusted branch repo by myself.
### What steps will reproduce the problem?
Synchronizing several git annex repositories (three) with the assistant, with the second one being in the adjusted branch:
* Create a new file in the first repository (normal v5, autocommit=true)
* The file is being commited automatically and synchronized into the 3rd repository (normal v5).
* But the file does not appear in the 2nd one, being in the adjusted branch
Once you trigger
git annex sync
in the 2nd repository, it seems the adjusted branch synchronizes with the master and the file appears.
The same happens with changes in files.
### What version of git-annex are you using? On what operating system?
* git-annex version: 6.20160511-1~ubuntu14.04.1~ppa1
* Linux 4.4.0-24-generic #43~14.04.1-Ubuntu x86_64
* Linux Mint 17.3 Rosa
### Please provide any additional information below.
Assistant log from adjust branch repo.
test7.txt is the new file created on other repo which didn't showed up immediately.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
(merging origin/git-annex into git-annex...)
To /home/sven/Temporary/Annex1
+ 9cc4eea...0e6c4ba git-annex -> synced/git-annex (forced update)
(started...)
(merging synced/git-annex into git-annex...)
(Merging into master...) Merge made by the 'recursive' strategy.
script.sh | 1 +
1 file changed, 1 insertion(+)
create mode 100644 script.sh
(Merging into adjusted branch...)
Updating 449f26f..09950df
Fast-forward
script.sh | 1 +
1 file changed, 1 insertion(+)
create mode 100644 script.sh
[2016-09-25 16:32:28.594537] Committer: Committing changes to git
(recording state in git...)
[2016-09-25 16:32:28.631525] Pusher: Syncing with origin
To /home/sven/Temporary/Annex1
0e6c4ba..578f070 git-annex -> synced/git-annex
9754018..38c3683 master -> synced/master
[2016-09-25 16:32:29.632224] Committer: Committing changes to git
(recording state in git...)
[2016-09-25 16:32:30.661338] Pusher: Syncing with origin
Everything up-to-date
(merging synced/git-annex into git-annex...)
(merging synced/git-annex into git-annex...)
(recording state in git...)
git-annex: Daemon is already running.
[2016-09-25 16:36:58.360139] Committer: Adding test7.txt
add test7.txt ok
[2016-09-25 16:36:58.476985] Committer: Committing changes to git
(recording state in git...)
[2016-09-25 16:36:58.494964] Pusher: Syncing with origin
Everything up-to-date
[2016-09-25 16:36:59.575623] Committer: Adding test7.txt
add test7.txt ok
[2016-09-25 16:36:59.578454] Committer: Committing changes to git
(recording state in git...)
[2016-09-25 16:37:00.506906] Pusher: Syncing with origin
Everything up-to-date
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I'm using git-annex a lot for synchronizing stuff between work, home, external backup discs, and now that I see the autocommit=false flag I'll surely start to use the assistant.
And the new adjust branch is perfect for one of my use cases, but not like it behaves right now.

64
doc/bugs/Metadata_charset_not_uniform.mdwn Normal file
View file

@ -0,0 +1,64 @@
### Please describe the problem.
Metadata are not stored in a consistent format. It seems more like git-annex chooses the "smallest" charset able to hold the data, i.e. US-ASCII, unless there are latin1 characters, and only UTF-8 if there are UTF-8 characters that are not in latin1
### What steps will reproduce the problem?
% git init
Initialized empty Git repository in /home/madduck/.tmp/cdt.GlIevu/.git/
% git annex init
init ok
(recording state in git...)
% date > a
% git annex add a
add a ok
(recording state in git...)
% git annex metadata -s one=$(echo US-ASCII | iconv -tus-ascii) a
metadata a
lastchanged=2016-09-25@13-18-57
one=US-ASCII
one-lastchanged=2016-09-25@13-18-57
ok
(recording state in git...)
% git annex metadata -s two=$(echo lätin1 | iconv -tlatin1) a
metadata a
lastchanged=2016-09-25@13-19-37
one=US-ASCII
one-lastchanged=2016-09-25@13-18-57
two=lätin1
two-lastchanged=2016-09-25@13-19-37
ok
(recording state in git...)
% git annex metadata -s three=$(echo unicode… | iconv -tutf8) a
metadata a
lastchanged=2016-09-25@13-19-41
one=US-ASCII
one-lastchanged=2016-09-25@13-18-57
three=unicode…
three-lastchanged=2016-09-25@13-19-41
two=lätin1
two-lastchanged=2016-09-25@13-19-37
ok
(recording state in git...)
% git annex metadata -g three a | iconv -tutf8
unicode…
% git annex metadata -g two a | iconv -tutf8
liconv: illegal input sequence at position 1
% git annex metadata -g one a | iconv -tutf8
US-ASCII
% git annex metadata -g two a | iconv -flatin1 -tutf8
lätin1
### What version of git-annex are you using? On what operating system?
6.20160808-1

7
doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="PaulK"
subject="comment 6"
date="2016-09-24T04:16:51Z"
content="""
Nope, no difference. Same \"ELF load command alignment not page-aligned\" errors as before.
"""]]

13
doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="PaulK"
subject="comment 7"
date="2016-09-25T03:08:40Z"
content="""
As an aside, just tried syncthing's arm verion, and I get a \"runtime: kernel page size (32768) is larger than runtime page size (4096)\" error. While their arm64 version also won't run.
Perhaps it's a similar issue with git-annex? Seems the page-size comes up in a number of contexts of people trying to get software running on the WD NAS.
Is there any way to adjust this page-size in the linker?
Thanks
"""]]

15
doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn Normal file
View file

@ -0,0 +1,15 @@
I've been planning to use git-annex to manage a collection of DVD-Rs (of photos and the like), something along [these lines](https://git-annex.branchable.com/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/), and especially this paragraph therein:
> If the [media is] not rewritable [which in my case it won't be; see below], I might try making the git-annex repo in a temporary directory on the hard disk, and then generating the ISO from that once I've filled it up. Should work fine, I might set "remote..annex-readonly" to true in git repos that had such a disk as a remote to let git-annex know to not try to write to it.
But then there's this bug report: [read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote](https://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/), and [Joey's comment]((http://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/#comment-67f204c3a4312bbda8ace305dbe0afbf):
> From a code complication POV, it's useful for git-annex to only support one version of repository at a time.
My concept depends on being able to restore files from my archive, N years and M git-annex versions later, using `git annex get` (after `git annex whereis` or the like to find out which volume to mount). If I can't count on the *get* to work -- and indeed, can pretty much count on it *not* to, after the next format-version bump -- this whole scheme sounds like a nonstarter.
> As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex.
This is an archive; therefore it will use write-once media -- if it were rewritable, it would be clobberable should something (including `git-annex upgrade`!) go wrong.
So, is there a way around this? Or am I (and others) out of luck on using git-annex to manage long-term archival storage?

8
doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
subject="+may be "byte-target" field? ;)"
date="2016-09-24T02:43:21Z"
content="""
THANK YOU for implementing this feature -- we will make use of it soon.
But so we don't do reverse estimation from \"byte-progress\" and \"percent-progress\", and didn't have to get it from a key (which might not have it e.g. in case of URL relaxed backend) -- could you just include in each record the \"byte-target\" (if known) or something like that? ;) thanks in advance!
"""]]

11
doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="erics"
subject="comment 4"
date="2016-09-25T00:33:56Z"
content="""
> And there is a complication with running [`git annex copy --from --to`] at the same time as eg `git annex get` of the same file. It would be surprising for get to succeed (because copy has already temporarily downloaded the file) and then have the file later get dropped.
A solution to this subproblem would transparently fall out of a facility for [logically dropping files](http://git-annex.branchable.com/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/#comment-9672d46a18a381971dd818cde6efbc33), which was briefly talked about a long time ago. Just mark the file as *logically dropped*. If the user `git annex get`s it while the copy-out is in progress, its status will change to \"present\", so *copy* will know not to physically delete it.
(Of course there are race conditions involved, but I presume/hope that they're no worse than git-annex already has to deal with.)
"""]]