Live data from Hacker News

How we use BitTorrent to improve our design sharing workflow

medium.com

11–20 of 27 posts

Re: How we use BitTorrent to improve our design sharing workflow

#13
post #11

" not to mention it means everyone who wants access needs to commit to losing 1TB of space on their hard drive." Dropbox has selective sync for years already, doesn't it?

Yup, but for some reason most people don't seem to know about it. They could set up a shared top level project directory with sub directories for each aspect of the project and then people only need to sync the stuff relevant to them.

Re: How we use BitTorrent to improve our design sharing workflow

#16

OP mentions this app "Arq" for AWS S3/Glacier backups. Does anyone know a similar app for Linux?

dschep is dead for some reason, so copying & pasting his answer so all can see:

Duplicity[0] supports it through a boto[1] backend. [0] http://duplicity.nongnu.org [1] https://github.com/boto/boto

Re: How we use BitTorrent to improve our design sharing workflow

#17
There's git-annex for git with big files: http://git-annex.branchable.com/

"git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, time, or disk space."

and

"The git-annex assistant creates a folder on each of your computers, Android devices, removable drives, and cloud services, which it keeps synchronised, so its contents are the same everywhere. It's very easy to use, and has all the power of git and git-annex."

Re: How we use BitTorrent to improve our design sharing workflow

#19
post #18

How does this handle a situation where multiple designers edit large files at roughly the same time?

I also always wondered if there was some version control system for pictures.

Github supports some basic features: https://github.com/blog/817-behold-image-view-modes

Re: How we use BitTorrent to improve our design sharing workflow

#20
post #3

I was hoping this was going to be something where the files themselves were distributed so that they didn't take up space on everyone's machines, a la MogileFS[1], but alas. This is always a point of pain for us: in our studios we work from a central file server, so our shiny iMacs with their 1TB drives all have about 90% capacity on them — but we don't have any easy way to pool all that extra capacity and use it eve…

That's what git-annex is for. Everyone has a list of all the files, and then if you want to access one, you can just do "git annex get [file]" and it'll get it from any of the machines that happen to have that file. If you want to delete it, "git annex drop [file]" will ensure at least N machines keep a copy of the file before deleting it. I use it to manage files between my VPS, desktop, laptop and NAS, with each ma…

Is there any way to get around the fact that adding a new machine involves adding N*2 remotes? (That is, one remote on each of the current machines to represent the new one; and then on the new machine, one remote for each existing machine). This seems like it would be the sticking point with Git annex.
Post reply on HN