Tahoe as git remote

[Daira Hopwood]

On 26/10/15 17:58, Greg Troxel wrote:
> 
> Jean-Rene David <tahoe-dev at levelnine.net> writes:
> 
>> Actually the reason I wanted to use tahoe as a
>> remote only was to avoid going the filesystem
>> route. There is a protocol to talk to remotes and
>> it's completely different (and hopefully simpler)
>> than implementing a filesystem layer.
>>
>> What I didn't know, and found out while
>> researching for this little project, is that git's
>> remote protocol is clearly defined in its own man
>> page and git even supports the addition of
>> user-defined transports. I stumbled upon the
>> gitremote-helpers man page and was very pleasantly
>> surprised.
> 
> The problem with this approach is that for N users and M filesystems one
> needs to write N*M adaptors.  This is why we have filesystem APIs and
> why we have IP.

Greg,

Please stop saying that Tahoe-LAFS should have better filesystem support every
time someone raises an issue with another interface, or suggests adding one.
These are independent issues.

The impedence mismatch between Tahoe-LAFS and the POSIX or Windows filesystem
interfaces is not easily, if at all, fixable. Furthermore, it isn't clear that
a FUSE-style layer is at all the right approach for improving that situation.

Our current approach for doing so is the Magic Folder project, which synchronizes
local directories (using any local filesystem) with Tahoe-LAFS as a backend.
This potentially has much better performance and application compatibility than
a FUSE-style layer possibly could.

In any case, supporting other interfaces, or fixing bugs in Tahoe's other frontends,
should not block on either Magic Folder or improved FUSE support.

-- 
Daira Hopwood  ⚧Ⓐ

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20151026/7c34ab84/attachment.pgp>