Note: This may not be a bug maybe the software doesn't work the way I think.
What steps will reproduce the problem?
Using the webapp, I created a normal repo on my desktop. I then added a 'Removable drive' repo on my usb stick.
I want all my files to be synced and accessibles on both repos so I set the 'Removable drive' repo to 'client'.
What is the expected output? What do you see instead?
When I look in the 'annex' folder on my usb stick. I see a git repo (annex, branches, hooks) instead of seeing the files in the same way the 'annex' repo on my desktop is.
What version of git-annex are you using? On what operating system?
I'm using 9e57edff287ac53fc4b1cefef7271e9ed17f2285 (Fri Feb 22 15:19:25 2013 +0000).
Ubuntu 12.10 x86_64
You have a bare git repository on your USB stick. The assistant uses bare repositories on USB sticks currently, although recent changes to support FAT make it possible to use non-bare repositories.
For this to really work the way you want it to, the assistant would need to start updating local non-bare repositories whenever it pushed changes to them. Currently the assistant only updates the repository it's running in, so a non-bare repository on USB would lag behind and show an old version of the directory until manually updated with
git annex sync.Struggling to get the assistant to behave properly, including a similar situation to the above.
I start the assistant with 'git annex webapp' and create an annex from the webapp. Adding an SSH remote (even if just a different directory on localhost) with "Remote server", creates the remote directory with what looks like what the contents of .git should be (annex, branches, hooks, objects etc.), regardless of the group chosen.
Judging from your above comment, this means it is creating a bare repository. Why would it be doing this for an SSH remote, where git-annex-shell is available?
System: Arch Linux git-annex version: 3.20130216 Installed with: yaourt -S git-annex-bin
Xyem, if you use git to clone a repo, instead of letting the assistant do it for you, you can get a non-bare repo. See the walkthrough for some examples. You can keep its working tree up to date with "git annex sync" run in that directory.
Only helpful if you don't mind using git annex at the command line, I know.
@edheil: Yes, I have found that creating the repositories outside of the assistant (or directly on each machine through the assistant) and adding the remotes manually doesn't have this issue.. but as I am not setting this up for myself, so dropping to the command line is an issue (she's not averse to it, but also isn't a power user).
It seems that the assistant/webapp is replacing dropbox functionality, while ignoring the functionality of git-annex. Perhaps I am misunderstanding the goal of it..?
My intended use case in the situation where this issue comes up is:
Repository on desktop has a copy of all files in indirect mode. Repository on netbook only has a copy of files added locally or fetched manually. Dropping a file in the netbook annex should cause it to be uploaded to the desktop repository (when it is available). Files should be fetchable/droppable (and unlockable) using the webapp from the desktop/netbook repository respectively.
But it looks like this is (currently) unachievable as the webapp provides no method of fetching/dropping files, the assistant does not create the remote repositories correctly and requires dropping to the command line if worked around. Eep!
Hope this doesn't come off as sour complaining. I was introduced to git-annex by a friend about a week ago (she only learned about it about 2-3 weeks ago and loves it) and it is a very nice and flexible tool which fits my own use case perfectly, meeting and exceeding every expectation.. until it came to the assistant and webapp (which makes me wonder why Joey is working on an Android port..).
There is a way to fetch/drop files if you don't want to use the command line, though it's not nearly as flexible as using a command line. If you've got a machine set as "client" then dragging files into a subdirectory named "archive" drops them, and dragging them out of that subdirectory fetches them.
Honestly, moving files in and out of directories, and preferred content settings, have both been subject to the occasional regression, so there have been times this hasn't worked right, but in theory, that's how you do it.
Unfortunately if you've got more than one "client" machine, this means adding/dropping files on one will affect them all, as file movements propagate.
The way this is supposed to (and does) work is that you use the webapp to create a repository on each computer, and then you pair them together using either local pairing or xmpp pairing.
Today's release of git-annex also adds UI in the webapp to create additional local repositories that are connected to the current repository. However these are not really intended to be put on removable drives since the assistant needs to be running on them to keep them up-to-date.
@Joey: As my use case is 1 person using multiple machines, I didn't think local/XMPP pairing was appropriate.
Local pairing because the netbook leaves the network the desktop machine is on, which is when transferring the files is wanted (otherwise, they would just use the desktop...). XMPP pairing description implies that it is for 2 different people (thus 2 different addresses). Can it be used where both annexes are using the same address? Or does the address also allow you to include the location (i.e. name@host.com/netbook)?
It definitely sounds like I am misunderstanding how this is supposed to work so I apologise for that. Please keep up the excellent work. git-annex is one of those tools I wish I had learned about a long time ago!
@edheil: Interesting workaround, thanks.
this is still really confusing. having to create the repo by hand is a really confusing step - i have setup an external drive to have my files with me as i move around, having to go through hoops to find them in a bare repository seems contrary to the spirit of "future proofing" inherent to git annex.
the solution i found was to
git initthe repo on the removable drive before adding it through the webapp. i hope this can eventually be fixed, as it led to confusion among many other users (e.g. Accessing files in bare repository, ?Adding a repository as a "remote server" creates a bare repository next to the existing one, remote server client repositories are bare!? and so on). --anarcat