> > YMMV, but in my experience (a) communication of the patches per se is > only an issue the first time I set up a branch, after that local > branches are cheap (though still way expensive compared to git or > Mercurial) and remote pulls are normally a tiny fraction of the > repo---almost all the time for a pull (which can be substantial) is > spent in handling the patch applications, not in transmitting data, > (b) a lot of my communication is one-to-one (eg, pushes are always to > a central repo, and many pulls are between me and one coworker), and > (c) git and Mercurial beat the tar out of everybody else at sucking > down data, so there's plenty of room for optimization of conventional > point-to-point transmissions (eg, use of HTTP pipelining has got a > lot of attention here over the last year), and examples of successful > technology are near at hand.
With fountain codes you can use UDB instead of TCP, because you don't care if packets arrive out of order, or even if they get dropped completely. This may improve performance for even point to point transfers. We have an application for fountain codes coming up. If we go through with it, I'll post a codec on hackage. Another thought on performance... Has any one considered an option for darcs to leave the repositories in constant contact with each other? For example, when someone does a record, the patch information could start trickling to the other repos. Then when someone issues a push or pull, the local repository simply changes state, as opposed to actually transferring data -- assuming the data has already been transfered. (It's probably best not to advertise this feature. Then your push/pulls could report incredible transfer rates; even when the repository is not connected to the network. Beat that git.) -Tom _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
