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

This commit is contained in:
Joey Hess 2013-06-17 11:01:07 -04:00
commit 6d48a69788
10 changed files with 192 additions and 1 deletions

View file

@ -0,0 +1,47 @@
### Please describe the problem.
Attempted to create a bup remote on the current system via ssh. It appears to have created the bup remote fine, but fails when sshing to it and does not add the remote.
This is a normal indirect annex (currently containing a single test jpg in its root)
I'm presuming the error is "(storing uuid...) sh: 1: cd: can't cd to /~/archie"
### What steps will reproduce the problem?
git annex initremote bup type=bup encryption=none buprepo=sshservername:path
I've tried using .ssh/config to remove the username from the servername passed to bup repo and it still fails.
### What version of git-annex are you using? On what operating system?
[[!format sh """
>git-annex version
git-annex version: 4.20130615-g29d5bb9
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
local repository version: 3
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 0 1 2
"""]]
debian wheezy i686
### Please provide any additional information below.
[[!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
> git annex initremote bup type=bup encryption=none buprepo=bup@localhost:archie
initremote bup (bup init...)
Reinitialized existing Git repository in /media/backup/home/archie/.bup/
Initialized empty Git repository in /media/backup/bup/archie/
(storing uuid...) sh: 1: cd: can't cd to /~/archie
git-annex: ssh failed
> ssh bup@localhost
Last login: Mon Jun 17 10:35:45 2013 from localhost
$ ls
archie
$ cd archie
$ ls
branches config description HEAD hooks info objects refs
# End of transcript or log.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-06-15T18:50:45Z"
content="""
Joe, you need to carefully read [[direct_mode]]. When you manually run `git merge` in a direct mode repository, you defeat associated file tracking, with the resulting behavior you describe. This is why there is a [[todo/direct_mode_guard]] todo item.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
nickname="Joe"
subject="comment 2"
date="2013-06-15T19:39:09Z"
content="""
joey, Thank you for the reply. I have read that and also read about the direct mode guard. I only used git merge because I was stuck and didn't know what else to do. I assume the proper way to refresh my backup repo is to git annex sync. That's what's failing with the non-fast-forward error. I don't know what to do from there. Thank you for any help.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
nickname="Joe"
subject="comment 3"
date="2013-06-16T13:27:36Z"
content="""
Making some progress. It looks like it needs a .map file for the newly added file when I pull in the backup repo. I'm tracing the various places addAssociatedFile gets called. It looks like sync should do it. I think that's what sets up the map. If I copy the map file from another repo, I'm able to call get annex get foo2.txt. So the key is getting that map file created.
"""]]

View file

@ -0,0 +1,76 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
nickname="Joe"
subject="comment 4"
date="2013-06-16T17:27:18Z"
content="""
I have a workaround that requires a small patch. I'm not sure why it's not creating the mapping, but I noticed that git annex fsck has a verifyDirectMapping which will create the mapping if it doesn't exist.
git annex fsck will throw an error on fixLinks and won't proceed to verifyDirectMapping if the map file doesn't exist. So, I needed a way to call verifyDirectMapping directly. My hack is to add an argument to git annex fsck to call verifyDirectMapping.
My workflow is this:
**repo1**:
[[!format sh \"\"\"
echo a > new.txt
git annex add .
git commit -m \"add a\"
git copy --to origin
git annex sync
\"\"\"]]
**repo2**:
[[!format sh \"\"\"
git annex sync
git annex pull origin synced/master
git annex fsck --verifyDirectMapping
git annex get .
\"\"\"]]
The new file comes down cleanly.
I'm sure there's a better way to do this to fix the core issue, but here's how I patched Fsck.hs as a minimal workaround
[[!format diff \"\"\"
diff --git a/Command/Fsck.hs b/Command/Fsck.hs
old mode 100644
new mode 100755
index 9af6a4a..97aabb8
--- a/Command/Fsck.hs
+++ b/Command/Fsck.hs
@@ -59,12 +60,16 @@ incrementalScheduleOption :: Option
incrementalScheduleOption = Option.field [] \"incremental-schedule\" paramTime
\"schedule incremental fscking\"
+verifyDirectMappingOption :: Option
+verifyDirectMappingOption = Option.flag [] \"verifyDirectMapping\" \"verifies direct mappings are consistent\"
+
options :: [Option]
options =
[ fromOption
, startIncrementalOption
, moreIncrementalOption
, incrementalScheduleOption
+ , verifyDirectMappingOption
]
seek :: [CommandSeek]
@@ -107,18 +112,23 @@ withIncremental = withValue $ do
start :: Maybe Remote -> Incremental -> FilePath -> (Key, Backend) -> CommandStart
start from inc file (key, backend) = do
numcopies <- numCopies file
- case from of
- Nothing -> go $ perform key file backend numcopies
- Just r -> go $ performRemote key file backend numcopies r
+ verify <- Annex.getFlag (Option.name verifyDirectMappingOption)
+ if verify
+ then go $ verifyDirectMapping key file
+ else
+ case from of
+ Nothing -> go $ perform key file backend numcopies
+ Just r -> go $ performRemote key file backend numcopies r
\"\"\"]]
"""]]