[darcs-users] peer to peer darcs

David Roundy droundy at abridgegame.org
Tue Aug 3 10:28:24 UTC 2004


On Mon, Aug 02, 2004 at 12:42:08PM -0400, S. Alexander Jacobson wrote:
> I don't think I understand the resource utilization issues.  It seems
> like if we arbitrarily assign a seniority order to the distribution list
> and if each patch has an id and is distributed with the patch-ids of
> patches it assumes have already been applied to the repos, then the
> computations feel relatively lightweight and low memory even if they are
> O(n^2).  Here is the workflow:
> ...

The method you describe is precisely what I would do (if I didn't have a
central server).  In this case the O(n^2) business won't really bite you,
since here n will be on the order of the number of developers who are
simultaneously making changes.

The situation where the O(n^2) would bite would be if you were to try to
reduce the context of each patch bundle to a minimal context (i.e. commute
the patch through any previous patches that it will commute by).  This is
O(n^2) in the number of patches in the history, which is serious.

> 3. Alice configures procmail to apply emailed changes to mirror and
> configures mirror to mail out any changes accepted from AliceActive with
> the list of all patchIds allready integrated into AliceMirror before the
> current change.

I would change this to using "send" for the patches moving into
AliceMirror, and include yourself in the target list of the send, and then
your procmail script will apply your changes to AliceMirror just the same
as everyone else's.

The busines of sending out changes along with a list of patchIds is
precisely what darcs send does.  So I think this way of working is easier
than you're thinking.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list