status of sharebox-fs?

[Joey Hess]

Christophe-Marie Duquesne wrote:
> No, I think you're refering to dvcs-autosync. Sharebox does not do
> that: instead, the plan is to offer a callback option for a program to
> be called whenever a git operation has been performed. The
> synchronisation itself should be called by touching a special file.
> This way, those who want instant updates might just plug for example a
> jabber bot that would advertise for modifications and touch this file
> whenever another peer advertises for modifications. Those who prefer
> to synchronise once a day in order to save battery should just use a
> crontask.

Ah indeed I'd forgotten about dvcs-autosync.

I've also been thinking about using special files to control various
operations.

> > NAT traversal is also a hard problem, when none of the repos have a public
> > IP address.
> 
> Yes, this is not an easy problem. I also thought about this issue. My
> conclusion: I think it should be easier to pretend every peers are on
> the same LAN, and build a vpn between them. Several possibilities:
> - Users could just self host their own vpn (requires knowledge).
> - Users could suscribe to a service that would provide the vpn (a way
> to make money with such a software?).
> - Some peer to peer vpn could be used. There are plenty of opensource
> programs for this job. gnunet provides a fine way to do that.
> My only problem with all the peer to peer vpn implementations is that,
> afaik, none of them works on every platform.

git-annex special remotes are one way to do it, if the user has an
account that can be used to interchange the data. It has to be made easy
enough to set up that a regular user can do it though.

> > Also interesting is finding the paths through the network
> > of repos that gets data transferred to each most efficiently.
> 
> What do you mean exactly?

Well, imagine there are two remotes, and they're both on the other side
of a cable modem. Ideally it should avoid sending the data to both, if
one can talk to the other. OTOH, if they're not otherwise connected,
it needs to double the transfer. You need to map the network (which
git-annex can already do) and analize the weighted graph.

> Btw, I did not look closely how git-annex has been modified recently,
> but the reason why I have chosen FUSE was the ability to present
> git-annexed files (ie symlinks to read only files) as regular files.
> IMHO, that would be the most user friendly way to manipulate these
> files without the user noticing git. However, from what I read on
> kickstarter, you might have found a better solution. What is it?

No, I punted on it. The inotify managed directory will behave
differently/annoyingly when the user tries to modify files.
This certianly doesn't perfectly cover every use case, but
I feel it's an ok tradeoff, you can get used to that behavior.

One potential use of special files is touching $file.edit to make
git-annex unlock $foo for editing, or perhaps touching .edit to unlock a
whole directory of files.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20120523/76d8d8d4/attachment.pgp>