[tahoe-dev] Free/Open alternatives to Dropbox

Zooko O'Whielacronx zooko at zooko.com
Tue May 17 21:08:28 UTC 2011


On Sat, May 14, 2011 at 6:42 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
> >  One way to do that would be to write glue code to let Tahoe-LAFS serve
> >  as a "back end" in some of these schemes. DVCS-Autosync, in
> >  particular, was designed with git in mind but allegedly can use any
> >  distributed revision control tool for its back end.
>
> I don't see tahoe as a distributed revision control scheme.

Do you think DVCS-Autosync needs a revision control scheme? From
glancing at the interface:

http://gitorious.org/dvcs-autosync/dvcs-autosync/blobs/8a19c6da18067330a6ed8a11e704678b5b741b70/dvcs-autosync#line538

I'm not sure how much people would miss the functionality if we just
used "tahoe cp" for cmd_push and cmd_pull. If people want the ability
to browse back in history then perhaps using "tahoe backup" for
cmd_push and "tahoe cp" for cmd_pull would do. I'm not sure. I hope
someone tries it! :-)

>   But one
> could store the git repo used for syncing in tahoe.

Yes, and this is also separately interesting! Nathan Wilcox posted a
hack to export your Mercurial history into a Tahoe-LAFS browsable
directory structure:
http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004559.html

> I've generally been of the opinion that backup (certainly) and syncing
> (maybe) belong above the filesystem so that they can be shared.
> syncing only belongs in the filesystem when it's part of the
> filesystem's fundamental concept of operations (like coda).

I don't know -- I think people should experiment. And share their results!

Regards,

Zooko



More information about the tahoe-dev mailing list