One more thing... on the open and transparent science front, if you are working on restricted use data, keeping your files in git directly obviously leads to disclosure. Git annex is a great solution than can let someone see the structure of your analysis (including data file names and locations), while storing these in a highly secure manner with separate access controls.
On Tue, Nov 18, 2014 at 12:02 PM, Dav Clark <[email protected]> wrote: > I've gone back and forth with git annex for a while. > > On Tue, Nov 18, 2014 at 8:22 AM, Luiz Irber <[email protected]> wrote: > >> I'm trying git-annex, it fits my workflow well because I can have >> subsets of my data in different machines. This way I can use one place >> with more space for backup and only keep the active files on others >> (like on my laptop or on scratch directories on HPC centers). >> > > I find git annex works quite well for managing large files. Its great to > be able to see where all your files are from a given git repo. I have yet > to get working with collaborators on this, but the tools for collaboration > are quite robust and allow for shared keys that are encrypted with multiple > GPG keys... Coordinating these files, encrypted, and further > access-controlled, for example via box.net or S3 should suffice for all > but the most sensitive data. There should be someone in your organization > who could speak to that concern. > > >> It is not trivial to install if you're going to build it from source, >> but they do have installers and prebuilt packages available. You can >> also play with the assistant, the dropbox-like file synchronization. >> > > It's available via homebrew and there are packages on major linux > distributions, which is definitely what I'd do. The haskell package > management system is pretty complex to install for just one package. > > I have not found a use for the assistant. I'm not sure who that's for. > Certainly, it moves away from a git-style workflow. Perhaps it would be > useful for less technically sophisticated collaborators? But it'd be a > pretty narrow slice of people - you still need to be somewhat technical to > understand what's going on... > > -- > Dav Clark > Data Scientist > Berkeley D-Lab + BIDS > bead.glass > 510-664-7000 > -- Dav Clark Data Scientist Berkeley D-Lab + BIDS bead.glass 510-664-7000
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
