I have recently jumped into git-annex, and have several TB stored in several remote annexes. I am able to sync to clients, and have some understanding of the operations needed to get files back etc.
So far I have used v5 in Ubuntu and Debian 8. I have tried out assistant but will leave this until I better understand how git-annex works. CLI is best for this learning.
I am however concerned re the upgrade path from v5 to v6. I have not been able to find a comprehensive strategy. I have tried git-annex v6 and have upgraded a client repo to v6.
All of my remote repos are v5, and to be honest I am very nervous about touching them.
I do have a test bed where I try out all things before doing so on my 'production' repos. So, I can play, break, redo, in safety.
Any direction as to formulating a game plan for upgrading my whole network of repos, clients, etc would be very much appreciated.
And, if I have missed this, a pointer would be good for sure.
Regards,
Stan
While it is obvious to all: this is amazing software. Genius.
since you haven't explicitly mentionned it, i'll just mention a pointer to the upgrades page which has specific instructions regarding upgrading repositories to the v6 layout.
as far as I know, you can just upgrade the git-annex program itself harmlessly. it will not upgrade your repositories without you deliberately running git-annex-upgrade.
then git-annex-upgrade will operate changes, but only on direct mode repositories, as far as i can tell. those repositories are switched to adjusted branches, which have their own set of issues right name, mostly limitations with the webapp but have also seen a few bugfixes on crippled filesystems recently.
i am personnally doing the "wait and see" game especially considering my specific use case for v6 (?hide missing files) has not been completely implemented yet. but I am of course using 6.x binaries without problems.
i am not the git-annex author, so take my comments with a grain of salt of course.
--anarcat
Many thanks for the reply. I did not add too much detail to my post as it was my first, and I was a bit shy.
I did do all of the steps indicated re v6. The binary has been fine for me also.
My question is a bit more complex as I am looking to apply v6 at some point to a set of distributed repos. Essentially it has the typical duplicated system topology: 2 remotes, several clients, each of which is linked to both remotes. Thus it will survive multiple failure scenarios.
I would be looking at the strategy of the order of repo upgrade. Say, a client first, and run a set of tests. And so on. Remotes last perhaps.
In any case I built a test bed as above and have been experimenting with a single client at a v6 repo.
So far it has been smooth, but right now I seem to be stuck where thinning is not having any effect: I still have a particular big file (1.5GB) in both the annex and the working dir. Lock remove the big file from the working dir, and leaves a link, and unlock restores the big file in the working dir. Yet, the annex still contains the big file no matter what. I was under the expectation that one of the big file copies would go away.
I'd encourage you to not upgrade any production repositories to v6 yet. It's still in beta state and has known problems. Currently all known problems are only innefficiencies, but there could also still be bugs.
When you do upgrade, you can upgrade your distibuted set of repos peicemeal. v5 and v6 fully interoperate, until you start unlocking files in the v6 clones of the repo. Once those unlocks get committed, the v5 clones of the repo won't be able to access the unlocked file contents, and you'll need to upgrade the clones then.
At some point in the future, I expect v6 mode to be done and then git-annex will automatically upgrade for you. So the easist approach is to just wait for that.
(Not addressing your problems with annex.thin here as you filed a separate forum post and bug report about that.)