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 2014-01-05 21:31:20 -04:00
commit 59ba42777f
5 changed files with 68 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_1_27fc71cadcbe6d5f146ffdb72b64689a._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.35"
subject="comment 1"
date="2014-01-05T18:26:10Z"
content="""
It's not clear to me that the accept message has anything to do with dbus.
Does the accept message continue being logged past this point? Does the log contain \"unable to bind to local socket\"?
Are you able to open the webapp? That's the part of git-annex that would use `accept()`..
"""]]

12
doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_2_0fb01ff463e7da6df2864186dc28f8e4._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://grossmeier.net/"
nickname="greg"
subject="comment 2"
date="2014-01-05T22:50:32Z"
content="""
The accept lines just keep coming and coming and coming and coming. About 58 of them between \"lost dbus connection...\" logs. There's interspersed \"Everything up-to-date\" and such.
grep'ing for \"unable\" across all daemon log files gives me nothing.
I haven't futzed with opening the webapp on the NAS yet. Correction: I just did try futzing and I fear there's something in the NAS software I need to figure out before I can do it successfully.
"""]]

15
doc/bugs/USB_drive_not_syncing/comment_1_de76bd6b9f8eb2489d4854a4c8ddd308._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.35"
subject="comment 1"
date="2014-01-05T18:52:08Z"
content="""
You seem to have already had a regular bare git repository on the drive at `/media/A-DATA UFD/annex`, and then used the webapp or command line to make an encrypted gcrypt repository in the same location. This is the only way I can explain you being able to run \"git annex get in `/media/A-DATA UFD/annex` and it do anything at all, and it also explains the \"warning: no common commits\" and the failure to sync.
So, you have some unholy mix of two different types of repositories in one location. The best way to untangle this is probably to go into the webapp and
in the settings menu next to that repository, choose Delete. This will get back the files that were stored in the gcrypt repository. (Or stop the assistant, and in `~/annex/` run `git annex get` to hopefully retrieve the files that it stored in the gcrypt repository, and then remove the gcrypt repository from .git/config).
You may then need to edit `/media/A-DATA UFD/annex/config` to remove the gcrypt-id setting. At that point, it should be possible to use the webapp to add the removable drive, which will see the git repository on there and use it.
I have re-tested that the webapp does not allow creating a gcrypt repository when a regular bare git repository already exists on a removable drive. IIRC there were some bugs in this area initially, but they've all been fixed for a while. It *is* possible to manually use `git annex initremote` at the command line to turn a regular bare git repository into a gcrypt repository.
"""]]

15
doc/bugs/import_memleak_from_the_assistant/comment_3_b193a4a0901c681b59a97b93b456765b._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.35"
subject="comment 3"
date="2014-01-05T20:41:35Z"
content="""
Well, EKG either cannot see the leak, or perhaps haskell profiling generally cannot see it. Don't have a lot of experience with EKG, it's just a lot easier to ask for than full ghc profiling data..
It's certainly useful information that you are constantly changing the files.
I have tried to replicate this setup, with a few hundred files, and writing random stuff to them repeatedly. The RSS did not grow at all despite repeatedly changing and committing the files.
I then tried adding a remote for it to sync with, and see evidence of a small leak there -- around 8 bytes per file transferred. The leak appears to be in the transfer code, not the git sync code; it happens with both git remotes and with directory special remotes.
"""]]

14
doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnRRUUZo3W7pAoRoST8P_l0PtUBhvYuzDg"
nickname="Lyle"
subject="exactly this use case: cloud remotes too small"
date="2014-01-06T00:31:34Z"
content="""
I want to store a lot of scientific data in git-annex and have only a specific subset of my often used data in a box.com account so it is quickly synced between computers (my home internet has a limited upload speed). My home server will store all the files as it has effectively unlimited space.
I basically want the opposite of archive for git-annex-assistant, I'd like to mark the box.com special remote to store every *except* a certain special directory called less used files or whatever, or vise-versa, only store a folder of often used files, the local clients would store everything and my home server would also store everything.
It seems like transfer control and the groups.log can do this but I'm just not sure how to actually set it up?
Thanks!
"""]]