From pasci.bach at gmail.com Wed Feb 9 09:28:02 2011 From: pasci.bach at gmail.com (Pascal Bach) Date: Wed, 9 Feb 2011 15:28:02 +0100 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: Hello I noticed that there are a lot of patches floating around in the unison-users mailing list especially for build purpose. And what I know from the (Non-)development status page unison isn't actively developed anymore but patches are still welcome. I think in the current situation a distributed version control system would be more useful as it would facilitate the inclusion of patch for other people than the maintainers. I thus propose that the main repository should switch to Git (Github.com or Gitorious.org for example). I already setup a mirror of the SVN repository on github were I keep a branch with some build patches. https://github.com/pascal-bach/Unison Please let me know what you think about my proposal. Best regards Pascal From newton at mit.edu Wed Feb 9 10:32:40 2011 From: newton at mit.edu (Ryan Newton) Date: Wed, 9 Feb 2011 10:32:40 -0500 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: Sounds great! I've been VERY happy with github. On Wed, Feb 9, 2011 at 9:28 AM, Pascal Bach wrote: > Hello > > I noticed that there are a lot of patches floating around in the > unison-users mailing list especially for build purpose. And what I > know from the (Non-)development status page unison isn't actively > developed anymore but patches are still welcome. > > I think in the current situation a distributed version control system > would be more useful as it would facilitate the inclusion of patch for > other people than the maintainers. > I thus propose that the main repository should switch to Git > (Github.com or Gitorious.org for example). > > I already setup a mirror of the SVN repository on github were I keep a > branch with some build patches. https://github.com/pascal-bach/Unison > > Please let me know what you think about my proposal. > > Best regards > Pascal > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at le-gall.net Wed Feb 9 10:56:41 2011 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Wed, 9 Feb 2011 15:56:41 +0000 (UTC) Subject: [Unison-hackers] Move Unison to Git References: Message-ID: Hello, On 09-02-2011, Pascal Bach wrote: > > I noticed that there are a lot of patches floating around in the > unison-users mailing list especially for build purpose. And what I > know from the (Non-)development status page unison isn't actively > developed anymore but patches are still welcome. > > I think in the current situation a distributed version control system > would be more useful as it would facilitate the inclusion of patch for > other people than the maintainers. > I thus propose that the main repository should switch to Git > (Github.com or Gitorious.org for example). > > I already setup a mirror of the SVN repository on github were I keep a > branch with some build patches. https://github.com/pascal-bach/Unison > > Please let me know what you think about my proposal. > There is also a forge for OCaml projects: http://forge.ocamlcore.org This is of course less bells and whistles than github UI but it already hosts the git repository of lablgtk for example (lablgtk being a deps of unison). If you want to have at the same time github and the forge, you can do like batteries (http://batteries.forge.ocamlcore.org) for which SCM and bugs are on github and the rest (mailing list, releases and news) on the OCaml Forge. Cheers, Sylvain Le Gall -- My company: http://www.ocamlcore.com Linkedin: http://fr.linkedin.com/in/sylvainlegall Start an OCaml project here: http://forge.ocamlcore.org OCaml blogs: http://planet.ocamlcore.org From bcpierce at cis.upenn.edu Wed Feb 9 11:20:59 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Wed, 9 Feb 2011 11:20:59 -0500 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: I must admit I'm not too excited about moving Unison to a different version control system. We've done it twice before, and each time it took two or three full days of fiddling before everything was completely working again. (It's not just a matter of moving the sources: the VCS is also involved in the version numbering mechanism, the procedure for remembering what's changed for inclusion in release messages, the mechanism for building and exporting new releases, ...) If there are active maintainers / compilers of Unison distributions who feel that they could do their jobs more effectively with commit rights to the main SVN repository, just let me know and we can make that happen. Best, - Benjamin On Feb 9, 2011, at 9:28 AM, Pascal Bach wrote: > Hello > > I noticed that there are a lot of patches floating around in the > unison-users mailing list especially for build purpose. And what I > know from the (Non-)development status page unison isn't actively > developed anymore but patches are still welcome. > > I think in the current situation a distributed version control system > would be more useful as it would facilitate the inclusion of patch for > other people than the maintainers. > I thus propose that the main repository should switch to Git > (Github.com or Gitorious.org for example). > > I already setup a mirror of the SVN repository on github were I keep a > branch with some build patches. https://github.com/pascal-bach/Unison > > Please let me know what you think about my proposal. > > Best regards > Pascal > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From pascal.bach at epfl.ch Wed Feb 9 12:05:23 2011 From: pascal.bach at epfl.ch (Pascal Bach) Date: Wed, 9 Feb 2011 18:05:23 +0100 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: > I must admit I'm not too excited about moving Unison to a different version control system. ?We've done it twice before, and each time it took two or three full days of fiddling before everything was completely working again. ?(It's not just a matter of moving the sources: the VCS is also involved in the version numbering mechanism, the procedure for remembering what's changed for inclusion in release messages, the mechanism for building and exporting new releases, ...) I have seen that the version numbering is strongly related to the SVN revision and it is true this would no longer be possible with git. I understand you concerns. So we probably don't need to switch revision control. But what do you think about setting ub an issue tracker? Currently the bugs are tracked either on the mailing list or in different buck trackers like the ones from Debian. I think it would be a good idea to have a central point where the patches and issues are collected. > If there are active maintainers / compilers of Unison distributions who feel that they could do their jobs more effectively with commit rights to the main SVN repository, just let me know and we can make that happen. It would be interesting to hear what version control the packagers use and if not SVN how you solve the problem that the program version numbering depends on SVN. If you are packager please let us know how you do it. Best Pascal From sylvain at le-gall.net Wed Feb 9 12:59:06 2011 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Wed, 9 Feb 2011 17:59:06 +0000 (UTC) Subject: [Unison-hackers] Move Unison to Git References: Message-ID: On 09-02-2011, Pascal Bach wrote: >> I must admit I'm not too excited about moving Unison to a different >> version control system. ?We've done it twice before, and each time it >> took two or three full days of fiddling before everything was >> completely working again. ?(It's not just a matter of moving the >> sources: the VCS is also involved in the version numbering mechanism, >> the procedure for remembering what's changed for inclusion in release >> messages, the mechanism for building and exporting new releases, ...) > > I have seen that the version numbering is strongly related to the SVN > revision and it is true this would no longer be possible with git. I > understand you concerns. > So we probably don't need to switch revision control. But what do you > think about setting ub an issue tracker? Currently the bugs are > tracked either on the mailing list or in different buck trackers like > the ones from Debian. I think it would be a good idea to have a > central point where the patches and issues are collected. On the OCaml Forge, you can keep SVN (and import history) and setup an issue tracker. I must admit that -- with my Debian packager hat -- I would gladly welcome an issue tracker. This will help to forward upstream a lot of bugs. Most of the time, I need to forward a bug from the Debian BTS and just don't do it, because I have no time to discuss it on the mailing list. The mailing list also doesn't provide a pragmatic way to know if the bug is closed or not... > > >> If there are active maintainers / compilers of Unison distributions >> who feel that they could do their jobs more effectively with commit >> rights to the main SVN repository, just let me know and we can make >> that happen. > > It would be interesting to hear what version control the packagers use > and if not SVN how you solve the problem that the program version > numbering depends on SVN. If you are packager please let us know how > you do it. > You can easily manage commit rights (just as any forge in fact) on the OCaml Forge, by adding people to the project. Cheers, Sylvain Le Gall -- My company: http://www.ocamlcore.com Linkedin: http://fr.linkedin.com/in/sylvainlegall Start an OCaml project here: http://forge.ocamlcore.org OCaml blogs: http://planet.ocamlcore.org From sylvain at le-gall.net Wed Feb 16 13:15:38 2011 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Wed, 16 Feb 2011 19:15:38 +0100 Subject: [Unison-hackers] GSoC for unison? Message-ID: <20110216181538.GB10461@yocto.gallu.homelinux.org> Hello all, Christophe and I are trying to coordinate OCaml community efforts to be accepted as mentor organization for this year GSoC. I think unison team can get some precious help from student through this kind of summer project. If some of you are willing to be sponsors, add your name to the mentors list: https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page Maybe the unison project can run its own GSoC mentoring organization, but I think we can benefit from a partnership. If we have enough mentors and proposals, this will ease Google acceptance of our mentor organization. Cheers Sylvain ----- Forwarded message from Christophe TROESTLER ----- Dear OCaml developers, Google Summer of Code has been announced and we think that the OCaml Community should participate to this event. We have setup a project on the OCaml Forge to coordinate our effort. We invite all students and would-be mentors to visit our wiki: https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page - If you are willing to be a mentor, you can make proposal (this will only be "draft" proposal, until one student pick it) and put the name on the mentor list: https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page#Contact - Students that would like to join can contact mentors of draft proposals or make new one and discuss them with possible mentors: https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/GSoC2011/Applying The first step we will have to pass is to have Google accept the OCaml Community as a Mentoring organization. To reach this goal, ideas are welcome. Some documents are available on this topic here: http://www.google-melange.com/ We also have put online a first version of our answers to Google questions (to be completed) : https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/MetaOrganization Best regards, C. Troestler and S. Le Gall ----- End forwarded message ----- -- My company: http://www.ocamlcore.com Linkedin: http://fr.linkedin.com/in/sylvainlegall Start an OCaml project here: http://forge.ocamlcore.org OCaml blogs: http://planet.ocamlcore.org From rrnewton at gmail.com Mon Feb 21 08:58:08 2011 From: rrnewton at gmail.com (Ryan Newton) Date: Mon, 21 Feb 2011 08:58:08 -0500 Subject: [Unison-hackers] A rant about problems with dropbox -- thank you Unison! Message-ID: Thank you unison for *correctness*. We had a thread discussing dropbox back in October. I was cautiously optimistic then but now am more jaded after the abysmal way they handle symlinks: http://parfunk.blogspot.com/2011/02/dropbox-semantics-oh-that-there-were.html Ironically, I end up recommending periodic unison to get the symlinks right and then dropbox for day to day synchronization! (Not a pleasant solution.) It's exactly as Benjamin Pierce says in the message below -- unison fails safely and gets cross-platform right. I've seen dropbox break both these rules so far. Ranting about the low quality of commercial synchronization solutions has become a bit of a hobby. For the sake of confirmation bias I would love to hear other people's bad stories about commercial synchronization solutions ;-) -- e.g. apple's iSync both lost my data and got into a failure mode exhibiting exponential duplication. It seems as though many companies treat synchronization as just another programming task and not worthy of deeper thought. BUT, Dropbox in particular still has a lot of draw -- super easy setup, cloud storage, and the wonderful file-browser-as-GUI methodology. I'm convinced that Unison could be the kernel of a great solution here. But in the past its been too much work for anyone to get excited about doing cross-platform inotify-style file system monitoring in particular. Are there other open source projects from which this functionality could be borrowed? iFolder? -Ryan P.S. Also, if anyone were interested the nautilus-plugin for dropbox is open-source and could be a starting point for file-browser integration. P.P.S. I don't know about cloud storage. I assume that S3 and google storage use APIs that would make it difficult to ever unison-to-cloud directly. (Without maybe running an EC2 instance with a unison server or something.) On Mon, Oct 5, 2009 at 10:02 AM, Benjamin Pierce wrote: > I've been hearing some good things about DropBox too. ?I'd love to > know more about people's experiences with it, especially compared to > Unison. > > Two things Unison is pretty good at are (1) failing safely when things > go wrong and (2) getting the details of cross-platform synchronization > right. ?I doubt if I'll personally want switch to anything that > doesn't do at least as good a job on both counts, so comments on these > aspects of DropBox would be particularly interesting. > > ? ?- Benjamin From bcpierce at cis.upenn.edu Tue Feb 22 08:40:19 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 22 Feb 2011 08:40:19 -0500 Subject: [Unison-hackers] GSoC for unison? In-Reply-To: <20110216181538.GB10461@yocto.gallu.homelinux.org> References: <20110216181538.GB10461@yocto.gallu.homelinux.org> Message-ID: <7E55011D-5FFC-4E6B-87CE-E877406581AD@cis.upenn.edu> Sounds like a good idea. I tried to add myself to the wiki, but apparently this requires an account. Feel free to add me as a potential mentor for unison-related projects. Best, - Benjamin On Feb 16, 2011, at 1:15 PM, Sylvain Le Gall wrote: > Hello all, > > Christophe and I are trying to coordinate OCaml community efforts to be > accepted as mentor organization for this year GSoC. > > I think unison team can get some precious help from student through this > kind of summer project. If some of you are willing to be sponsors, add > your name to the mentors list: > https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page > > Maybe the unison project can run its own GSoC mentoring organization, > but I think we can benefit from a partnership. > > If we have enough mentors and proposals, this will ease Google > acceptance of our mentor organization. > > Cheers > Sylvain > > ----- Forwarded message from Christophe TROESTLER ----- > > Dear OCaml developers, > > Google Summer of Code has been announced and we think that the OCaml > Community should participate to this event. We have setup a project on > the OCaml Forge to coordinate our effort. > > We invite all students and would-be mentors to visit our wiki: > https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page > > - If you are willing to be a mentor, you can make proposal (this will > only be "draft" proposal, until one student pick it) and put the > name on the mentor list: > https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/Main_Page#Contact > > - Students that would like to join can contact mentors of draft > proposals or make new one and discuss them with possible mentors: > https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/GSoC2011/Applying > > The first step we will have to pass is to have Google accept the OCaml > Community as a Mentoring organization. To reach this goal, ideas are > welcome. Some documents are available on this topic here: > http://www.google-melange.com/ We also have put online a first > version of our answers to Google questions (to be completed) : > https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/MetaOrganization > > Best regards, > C. Troestler and S. Le Gall > > > ----- End forwarded message ----- > > -- > My company: http://www.ocamlcore.com > Linkedin: http://fr.linkedin.com/in/sylvainlegall > Start an OCaml project here: http://forge.ocamlcore.org > OCaml blogs: http://planet.ocamlcore.org > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From sylvain at le-gall.net Tue Feb 22 08:53:30 2011 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Tue, 22 Feb 2011 13:53:30 +0000 (UTC) Subject: [Unison-hackers] GSoC for unison? References: <20110216181538.GB10461@yocto.gallu.homelinux.org> <7E55011D-5FFC-4E6B-87CE-E877406581AD@cis.upenn.edu> Message-ID: Hello, On 22-02-2011, Benjamin C. Pierce wrote: > Sounds like a good idea. > > I tried to add myself to the wiki, but apparently this requires an > account. Feel free to add me as a potential mentor for unison-related > projects. > I have added you to the list. Feel free to send me draft proposals. See the list here: https://forge.ocamlcore.org/plugins/mediawiki/wiki/gsoc-team/index.php/GSoC2011/Applying You can create an account and edit the wiki yourself, if you register here: https://forge.ocamlcore.org/account/register.php Cheers Sylvain -- My company: http://www.ocamlcore.com Linkedin: http://fr.linkedin.com/in/sylvainlegall Start an OCaml project here: http://forge.ocamlcore.org OCaml blogs: http://planet.ocamlcore.org From bcpierce at cis.upenn.edu Tue Feb 22 14:56:06 2011 From: bcpierce at cis.upenn.edu (Pierce Benjamin C.) Date: Tue, 22 Feb 2011 14:56:06 -0500 Subject: [Unison-hackers] A rant about problems with dropbox -- thank you Unison! In-Reply-To: References: Message-ID: > I'm convinced that Unison could be the kernel of a great solution > here. But in the past its been too much work for anyone to get > excited about doing cross-platform inotify-style file system > monitoring in particular. Are there other open source projects from > which this functionality could be borrowed? iFolder? Actually, this functionality is pretty close to working -- what it needs is for someone who cares about a particular platform to take it on and polish off a few remaining rough edges. Moreover, this can be done with minimal OCaml knowledge, as the actual FS monitoring code is written in Python... - B On Feb 21, 2011, at 8:58 AM, Ryan Newton wrote: > Thank you unison for *correctness*. > > We had a thread discussing dropbox back in October. I was cautiously > optimistic then but now am more jaded after the abysmal way they > handle symlinks: > http://parfunk.blogspot.com/2011/02/dropbox-semantics-oh-that-there-were.html > > Ironically, I end up recommending periodic unison to get the symlinks > right and then dropbox for day to day synchronization! (Not a > pleasant solution.) It's exactly as Benjamin Pierce says in the > message below -- unison fails safely and gets cross-platform right. > I've seen dropbox break both these rules so far. > > Ranting about the low quality of commercial synchronization solutions > has become a bit of a hobby. For the sake of confirmation bias I > would love to hear other people's bad stories about commercial > synchronization solutions ;-) -- e.g. apple's iSync both lost my data > and got into a failure mode exhibiting exponential duplication. It > seems as though many companies treat synchronization as just another > programming task and not worthy of deeper thought. > > BUT, Dropbox in particular still has a lot of draw -- super easy > setup, cloud storage, and the wonderful file-browser-as-GUI > methodology. > > I'm convinced that Unison could be the kernel of a great solution > here. But in the past its been too much work for anyone to get > excited about doing cross-platform inotify-style file system > monitoring in particular. Are there other open source projects from > which this functionality could be borrowed? iFolder? > > -Ryan > > P.S. Also, if anyone were interested the nautilus-plugin for dropbox > is open-source and could be a starting point for file-browser > integration. > > P.P.S. I don't know about cloud storage. I assume that S3 and google > storage use APIs that would make it difficult to ever unison-to-cloud > directly. (Without maybe running an EC2 instance with a unison server > or something.) > > > On Mon, Oct 5, 2009 at 10:02 AM, Benjamin Pierce wrote: >> I've been hearing some good things about DropBox too. I'd love to >> know more about people's experiences with it, especially compared to >> Unison. >> >> Two things Unison is pretty good at are (1) failing safely when things >> go wrong and (2) getting the details of cross-platform synchronization >> right. I doubt if I'll personally want switch to anything that >> doesn't do at least as good a job on both counts, so comments on these >> aspects of DropBox would be particularly interesting. >> >> - Benjamin > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From newton at mit.edu Wed Feb 23 16:34:04 2011 From: newton at mit.edu (Ryan Newton) Date: Wed, 23 Feb 2011 16:34:04 -0500 Subject: [Unison-hackers] A rant about problems with dropbox -- thank you Unison! In-Reply-To: References: Message-ID: Great! I spoke too soon. I was out of date -- I should have searched and I'd have seen all those messages about fsmonitor.py ;-)... Thanks, -Ryan P.S. The HEAD isn't building for me right this second, but is the state of affairs still as laid out in the manual. Namely, that the implementation polls a watchfile every few seconds: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/beta/unison-manual.html Is there a reason that it polls and then sleeps for a few seconds? If the watchfile were a pipe couldn't the unison process just do blocking reads against it to achieve better latency? (Usually I use "-repeat 1" when I'm editing on one machine and compiling on another.) On Tue, Feb 22, 2011 at 2:56 PM, Pierce Benjamin C. wrote: >> I'm convinced that Unison could be the kernel of a great solution >> here. ?But in the past its been too much work for anyone to get >> excited about doing cross-platform inotify-style file system >> monitoring in particular. ?Are there other open source projects from >> which this functionality could be borrowed? ?iFolder? > > Actually, this functionality is pretty close to working -- what it needs is for someone who cares about a particular platform to take it on and polish off a few remaining rough edges. ?Moreover, this can be done with minimal OCaml knowledge, as the actual FS monitoring code is written in Python... > > ? ?- B > > > On Feb 21, 2011, at 8:58 AM, Ryan Newton wrote: > >> Thank you unison for *correctness*. >> >> We had a thread discussing dropbox back in October. ?I was cautiously >> optimistic then but now am more jaded after the abysmal way they >> handle symlinks: >> ? ?http://parfunk.blogspot.com/2011/02/dropbox-semantics-oh-that-there-were.html >> >> Ironically, I end up recommending periodic unison to get the symlinks >> right and then dropbox for day to day synchronization! ?(Not a >> pleasant solution.) ?It's exactly as Benjamin Pierce says in the >> message below -- unison fails safely and gets cross-platform right. >> I've seen dropbox break both these rules so far. >> >> Ranting about the low quality of commercial synchronization solutions >> has become a bit of a hobby. ?For the sake of confirmation bias I >> would love to hear other people's bad stories about commercial >> synchronization solutions ;-) -- e.g. apple's iSync both lost my data >> and got into a failure mode exhibiting exponential duplication. ?It >> seems as though many companies treat synchronization as just another >> programming task and not worthy of deeper thought. >> >> BUT, Dropbox in particular still has a lot of draw -- super easy >> setup, cloud storage, and the wonderful file-browser-as-GUI >> methodology. >> >> I'm convinced that Unison could be the kernel of a great solution >> here. ?But in the past its been too much work for anyone to get >> excited about doing cross-platform inotify-style file system >> monitoring in particular. ?Are there other open source projects from >> which this functionality could be borrowed? ?iFolder? >> >> -Ryan >> >> P.S. Also, if anyone were interested the nautilus-plugin for dropbox >> is open-source and could be a starting point for file-browser >> integration. >> >> P.P.S. I don't know about cloud storage. ?I assume that S3 and google >> storage use APIs that would make it difficult to ever unison-to-cloud >> directly. ?(Without maybe running an EC2 instance with a unison server >> or something.) >> >> >> On Mon, Oct 5, 2009 at 10:02 AM, Benjamin Pierce wrote: >>> I've been hearing some good things about DropBox too. ?I'd love to >>> know more about people's experiences with it, especially compared to >>> Unison. >>> >>> Two things Unison is pretty good at are (1) failing safely when things >>> go wrong and (2) getting the details of cross-platform synchronization >>> right. ?I doubt if I'll personally want switch to anything that >>> doesn't do at least as good a job on both counts, so comments on these >>> aspects of DropBox would be particularly interesting. >>> >>> ? ?- Benjamin >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at lists.seas.upenn.edu >> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From bcpierce at cis.upenn.edu Wed Feb 23 21:32:32 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Wed, 23 Feb 2011 21:32:32 -0500 Subject: [Unison-hackers] A rant about problems with dropbox -- thank you Unison! In-Reply-To: References: Message-ID: <1374DD25-6C11-4A66-A4EC-3562EECE4DF4@cis.upenn.edu> > ... is the > state of affairs still as laid out in the manual. Namely, that the > implementation polls a watchfile every few seconds: > > http://www.cis.upenn.edu/~bcpierce/unison/download/releases/beta/unison-manual.html > > Is there a reason that it polls and then sleeps for a few seconds? If > the watchfile were a pipe couldn't the unison process just do blocking > reads against it to achieve better latency? (Usually I use "-repeat > 1" when I'm editing on one machine and compiling on another.) It could, but then the file watcher process might get blocked if the pipe filled up, which might cause it to miss some updates... "Every few seconds" could be every second, if you like. Or less. - Benjamin > > > > On Tue, Feb 22, 2011 at 2:56 PM, Pierce Benjamin C. > wrote: >>> I'm convinced that Unison could be the kernel of a great solution >>> here. But in the past its been too much work for anyone to get >>> excited about doing cross-platform inotify-style file system >>> monitoring in particular. Are there other open source projects from >>> which this functionality could be borrowed? iFolder? >> >> Actually, this functionality is pretty close to working -- what it needs is for someone who cares about a particular platform to take it on and polish off a few remaining rough edges. Moreover, this can be done with minimal OCaml knowledge, as the actual FS monitoring code is written in Python... >> >> - B >> >> >> On Feb 21, 2011, at 8:58 AM, Ryan Newton wrote: >> >>> Thank you unison for *correctness*. >>> >>> We had a thread discussing dropbox back in October. I was cautiously >>> optimistic then but now am more jaded after the abysmal way they >>> handle symlinks: >>> http://parfunk.blogspot.com/2011/02/dropbox-semantics-oh-that-there-were.html >>> >>> Ironically, I end up recommending periodic unison to get the symlinks >>> right and then dropbox for day to day synchronization! (Not a >>> pleasant solution.) It's exactly as Benjamin Pierce says in the >>> message below -- unison fails safely and gets cross-platform right. >>> I've seen dropbox break both these rules so far. >>> >>> Ranting about the low quality of commercial synchronization solutions >>> has become a bit of a hobby. For the sake of confirmation bias I >>> would love to hear other people's bad stories about commercial >>> synchronization solutions ;-) -- e.g. apple's iSync both lost my data >>> and got into a failure mode exhibiting exponential duplication. It >>> seems as though many companies treat synchronization as just another >>> programming task and not worthy of deeper thought. >>> >>> BUT, Dropbox in particular still has a lot of draw -- super easy >>> setup, cloud storage, and the wonderful file-browser-as-GUI >>> methodology. >>> >>> I'm convinced that Unison could be the kernel of a great solution >>> here. But in the past its been too much work for anyone to get >>> excited about doing cross-platform inotify-style file system >>> monitoring in particular. Are there other open source projects from >>> which this functionality could be borrowed? iFolder? >>> >>> -Ryan >>> >>> P.S. Also, if anyone were interested the nautilus-plugin for dropbox >>> is open-source and could be a starting point for file-browser >>> integration. >>> >>> P.P.S. I don't know about cloud storage. I assume that S3 and google >>> storage use APIs that would make it difficult to ever unison-to-cloud >>> directly. (Without maybe running an EC2 instance with a unison server >>> or something.) >>> >>> >>> On Mon, Oct 5, 2009 at 10:02 AM, Benjamin Pierce wrote: >>>> I've been hearing some good things about DropBox too. I'd love to >>>> know more about people's experiences with it, especially compared to >>>> Unison. >>>> >>>> Two things Unison is pretty good at are (1) failing safely when things >>>> go wrong and (2) getting the details of cross-platform synchronization >>>> right. I doubt if I'll personally want switch to anything that >>>> doesn't do at least as good a job on both counts, so comments on these >>>> aspects of DropBox would be particularly interesting. >>>> >>>> - Benjamin >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at lists.seas.upenn.edu >>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers >> >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at lists.seas.upenn.edu >> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers >>