I have a NAS at home which I access both as AFP/SMB shares and thru ssh/rsync. Now, I'd like to keep on using the shares as before, i.e., browsable via AFP/SMB with conventional file names. Ideally, I'd also like to git-annex some NAS shares, preferably, in direct mode. However, it seems out of the question to install git-annex on the NAS (hopefully, I'm wrong about this in the long run).
Two non-special remote setups would be:
- Mount the share and turn it into a direct mode git annex repo. Does anybody have experience with this? I'd suspect this to be very inefficient due to the use of all the files in .git over AFP/SMB. Configuration as a WORM backend seems to be advised? (Edit: Well, I just tried this and 'git annex init' failed as described in this forum post. So AFP/SMB seem to be non-starters.
Furthermore, AFP/SMB are immediately detected as crippled and set to direct mode automatically.) - Same as 1. but with a local GIT_DIR. This should work by having .git on the NAS link to the local GIT_DIR.
Alternatively, I could treat my NAS as a web special remote. Some URL schemes come to mind:
- file: This would benefit from some wish list items (recursive directory remote setup/addurl).
- rsync: AFAIK not implemented (yet?) as an option for web special remotes.
- sftp: (Might also include ssh access.)
The problem is that the "web semantics" don't really work in my use case:
- Files might change/move on the NAS.
- I'd like changes (e.g., renamed files) in my local repo to propagate to the NAS. Currently, git-annex would use git push for this purpose IIUC, however that's not available on the NAS...
- the web semantics seem to imply that there is exactly one "web" repository (and the URL is fixed)
All of these indicate a mismatch between my use case and web special remotes.
Hence my question: Would something like a "direct special remote" make sense?
As a starting point I'd look at a setup similar to 2. above, i.e., a remote "working copy" with local GIT_DIR. Except that instead of a whole local .git directory a branch in an existing .git dir might be more appropriate...
--Chris
If I understand this right, it is not possible to use git-annex as a simple wrapper around rsync.
My use case is this: I have a music folder on a plug computer running debian squeeze. The plug computer acts as a streaming music server. My wish is to create a local ssh remote to have my laptop git-annex music repo in sync with the plug computer. So ideally I don't want to install git-annex on the plug computer (but git is there so a git bare repo can be used).
According to the UI, if I use "Pairing with a local computer", both computers needs to have git-annex installed. If I try "Remote server" either I need both machines git-annex aware or I need the content of the plug computer to be encrypted (which is obviously not what I want in this case).
Is the use case supported by the UI ? Should I try with the CLI ?
Thanks for your help
@pradermecker: I think that the CLI would be able to do what you're describing (to some extent), but the issue is that the filenames it creates will be hashes, and not in the folder pattern that is on your laptop. Of course, if the plug computer uses file metadata to determine file info, and will search a directory tree, then it probably won't care that the files are named strange things.
As a quick example:
I have a repo with three files in it:
I copy those files to a directory remote:
Then I look at what's in my directory remote:
I haven't checked, but I think that the assistant will be able to use a special remote that you create from the CLI once you create it.
To create a remote without encryption using the CLI, try a command of the form
git annex initremote remote-name blah blah blah encryption=noneAlso see the information at directory, rsync, and Repo accessible from "dumb" client without git-annex.Thanks !
Before trying the CLI, I will install have a go with installing git-annex on the plug computer.
Do you know by any chance if version 3.20120629~bpo60+2 (the available version on squeeze-backport) will be compatible with the current latest release (4.20130405) ?
I guess I am asking if version 3 is compatible with version 4.