[tahoe-dev] Free/Open alternatives to Dropbox
Zooko O'Whielacronx
zooko at zooko.com
Tue May 17 14:08:28 PDT 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