headers
David Roundy | 1 Aug 2004 12:33

Re: peer to peer darcs

On Sat, Jul 31, 2004 at 06:39:46PM -0400, Andrew Pimlott wrote:
> On Sat, Jul 31, 2004 at 06:15:43AM -0400, David Roundy wrote:
> > Oh, I get it.  You could commute the patches into a minimal context,
> > yes, that would be very clever (and I even thought about doing
> > something like this at one time).  This would be a nice feature.
> 
> Then I guess that's what I meant.  :-)

:)

> > The only problem is that
> > it could be very slow, O(n^2) in the worst case sceneario, in which half
> > the patches in the repo are in the minimal context.  Specifying a tag to
> > keep in the context would greatly alleviate the slowness problem, but would
> > perhaps over-complicate the feature.  I guess something like
> > 
> > darcs send --to me <at> work --to-tag 0.9.23 --minimal-context
> > 
> > I'm not sure whether --to-tag would be appropriate, meaning I'm sending to
> > a person who I know has version 0.9.23, or --from-tag, meaning push changes
> > since 0.9.23.
> 
> I think we want to select the changes as usual, and separately say
> pretend I'm sending this to a repository at such-and-such tag.  So I
> guess you can get this feature today simply by maintaining such a
> repository.  Except in a distributed system, a tag might not be the
> right thing....  Maybe you just delay applying new patches to that repo
> for say one day (or week, or month, ...) and hope that's good enough.

Well, the difference is that if you do that today, you'll end up pushing
(Continue reading)

Permalink | Reply | 23 comments |
headers
Eric S. Johansson | 1 Aug 2004 17:18

Re: peer to peer darcs

Andrew Pimlott wrote:
> 
> Anyhow, on today's internet, you probably don't have to worry about
> people getting so far out of sync that this is really an issue.  Or am I
> wrong?

I think you are overly optimistic.  Today's Internet is mostly broken 
into consume only notes and a few producers.  For peer-to-peer 
operations, you need end-to-end completeness and that just isn't happening.

Bass assumption for distributed darcs should be:

Consume only connection
ability to serve *only* files by HTTP on "not under your control" server
pop 3 e-mail inbound/SMTP outbound.

the two modes of operations for repository owners that I think makes 
sense are change-test-release and changes visible on check-in.  In 
either case you have a discrete trigger event which can be used to 
replicate information or communicate to other members of a group.

instead of hardwiring a particular solution of how to propagate 
information that creates a trigger event, I would like to see the 
ability to call an external function/program in response to the trigger 
event.  Some supplied responses could be wrappers for FTP, rsync or mail 
to handle propagation of data.  for example the FTP or rsync wrappers 
could push data to a web site where others could then see the repository.

from the consumer side, maybe it's just my style but I can't see getting 
automatic updates except as e-mail notices saying that something changed
(Continue reading)

Permalink | Reply | 7 comments |
headers
S. Alexander Jacobson | 1 Aug 2004 20:26

Re: Re: peer to peer darcs

On Sun, 1 Aug 2004, Eric S. Johansson wrote:
> > Anyhow, on today's internet, you probably don't have to worry about
> > people getting so far out of sync that this is really an issue.  Or am I
> > wrong?

The maximum out-of-syncness is the duration of the
period between batch retrievals/sends of email.

If your workgroup includes people who are actively
producing patches with long periods between such
connections, then you probably have to handle that
specially no matter what revision control system
you are using.

However, I think, in most workgroups, a 2-3 day
period assumption seems entirely reasonable and
workable...

> I think you are overly optimistic.  Today's Internet is mostly broken
> into consume only notes and a few producers.  For peer-to-peer
> operations, you need end-to-end completeness and that just isn't happening.

You have end-to-end completeness for asynchronous
communications via email and arguably instant
messaging (e.g. Jabber).

> again personally, sending changes by SMTP doesn't really fit with my
> development style so I can't evaluate whether or not its useful.
> Apparently it works for some and I'm glad it does.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Samuel A. Falvo II | 1 Aug 2004 20:30

Re: Re: peer to peer darcs

On Sunday 01 August 2004 08:18 am, Eric S. Johansson wrote:
> I think you are overly optimistic.  Today's Internet is mostly broken
> into consume only notes and a few producers.  For peer-to-peer
> operations, you need end-to-end completeness and that just isn't
> happening.
>
> Bass assumption for distributed darcs should be:
>
> Consume only connection
> ability to serve *only* files by HTTP on "not under your control"
> server pop 3 e-mail inbound/SMTP outbound.

The Internet has always been, and always will be, inherently 
client-server.  Even such "peer-to-peer" services are all built on the 
client-server model.

A true peer-to-peer network requires a single, shared, broadcast-capable 
medium.  This, however, represents a net loss in total, aggregate 
bandwidth[1].  Therefore, to get around this, the client-server model is 
used, which enables aggregate bandwidth to be increased substantially, 
thus cutting costs astronomically.  

> trigger event.  Some supplied responses could be wrappers for FTP,
> rsync or mail to handle propagation of data.  for example the FTP or
> rsync wrappers could push data to a web site where others could then
> see the repository.

Oooh, I'd like that a lot.  Right now, every time I make changes to my 
local repository, when I'm ready to publish, I have to tag it, then 
manually upload it to the website repository (which will not let me run
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ketil Malde | 1 Aug 2004 22:09
Picon
Picon

Re: peer to peer darcs

"S. Alexander Jacobson" <alex <at> alexjacobson.com> writes:

> I would like to create a setup in which
> the repository contains a distribution list file.

There's been a lot of comment on this, so I won't address it, but

> Can darcs be used without any centralized repository at all (without
> requiring any particular machine to be available 24x7)?

The wording puzzles me.  Surely, you don't need 24/7 operation of the
central ("mother") repository, in particular if it accepts email
pushes.  And the whole point of darcs is that it is distributed;
patches go directly between any two repositories, so there's no
requirement for any repo to be central (even though it could be a
practical way to organize things)

Is there any particular reason you need a mailing list setup? 

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Permalink | Reply | 0 comments |
headers
Eric S. Johansson | 2 Aug 2004 00:15

Re: peer to peer darcs

S. Alexander Jacobson wrote:

> On Sun, 1 Aug 2004, Eric S. Johansson wrote:
> 
>>>Anyhow, on today's internet, you probably don't have to worry about
>>>people getting so far out of sync that this is really an issue.  Or am I
>>>wrong?
> 
> 
> The maximum out-of-syncness is the duration of the
> period between batch retrievals/sends of email.
> 
> If your workgroup includes people who are actively
> producing patches with long periods between such
> connections, then you probably have to handle that
> specially no matter what revision control system
> you are using.
> 
> However, I think, in most workgroups, a 2-3 day
> period assumption seems entirely reasonable and
> workable...

it really depends on the impact synchronization has on your development. 
  Personally, I tend to compartmentalize my work so that I don't need to 
synchronize very often and when I do so, it's a control process.  Other 
people need to have up-to-the-minute synchronization because they are 
doing integration work and the environment is totally 
uncontrolled/chaotic.  These really are two different models and need to 
be handled appropriately.  Usually through non configuration management 
means (i.e. talking to one another)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Pimlott | 2 Aug 2004 04:47

Re: peer to peer darcs

On Sun, Aug 01, 2004 at 06:33:21AM -0400, David Roundy wrote:
> On Sat, Jul 31, 2004 at 06:39:46PM -0400, Andrew Pimlott wrote:
> > I think we want to select the changes as usual, and separately say
> > pretend I'm sending this to a repository at such-and-such tag.  So I
> > guess you can get this feature today simply by maintaining such a
> > repository.  Except in a distributed system, a tag might not be the
> > right thing....  Maybe you just delay applying new patches to that repo
> > for say one day (or week, or month, ...) and hope that's good enough.
> 
> Well, the difference is that if you do that today, you'll end up pushing
> all needed patches that aren't in that repo

Huh?  You still select exactly the patches you want to send.  If none of
them depend on any patches not in the tag, it sends exactly these
patches with a context containing only the tag.

> , while the "minimal" patch
> method would push only those patches selected, but in a context that only
> contains patches that are depended upon by the patches you're pushing.

Right, but I thought we were talking about the middle ground, where you
assume everyone has at least a tag.  However, a few seconds more thought
should have made it obvious that you can achieve a minimal context: just
send your patch to an empty repository!  I tried this, works fine.

Andrew
Permalink | Reply | 0 comments |
headers
Andrew Pimlott | 2 Aug 2004 04:52

Re: peer to peer darcs

On Sun, Aug 01, 2004 at 06:33:21AM -0400, David Roundy wrote:
> Well, the difference is that if you do that today, you'll end up pushing
> all needed patches that aren't in that repo, while the "minimal" patch
> method would push only those patches selected, but in a context that only
> contains patches that are depended upon by the patches you're pushing.

Never mind my last message, I get the distinction now: whether the
needed patches are sent as patches, or as part of the context.

Andrew
Permalink | Reply | 0 comments |
headers
Andrew Pimlott | 2 Aug 2004 04:57

Re: peer to peer darcs

On Sun, Aug 01, 2004 at 06:33:21AM -0400, David Roundy wrote:
> Well, the difference is that if you do that today, you'll end up pushing
> all needed patches that aren't in that repo, while the "minimal" patch
> method would push only those patches selected, but in a context that only
> contains patches that are depended upon by the patches you're pushing.

Ok, last reply to this message!  Here's how you get it today:

    1.  Push selected patches to an empty repository.
    2.  Unpull selected patches from empty repository.
    3.  Send selected patches to the empty repository.

The post that last send to the world.  Right?

Andrew
Permalink | Reply | 20 comments |
headers
Andrew Pimlott | 2 Aug 2004 05:09

Re: Re: peer to peer darcs

On Sun, Aug 01, 2004 at 02:26:48PM -0400, S. Alexander Jacobson wrote:
> On Sun, 1 Aug 2004, Eric S. Johansson wrote:
> > > Anyhow, on today's internet, you probably don't have to worry about
> > > people getting so far out of sync that this is really an issue.  Or am I
> > > wrong?
> 
> The maximum out-of-syncness is the duration of the
> period between batch retrievals/sends of email.

Remember David's point:  It's only a problem when Alice gets patch A,
applies it, and produces patch B (including A in the context), and Bob
gets patch B before patch A is available to him.  I can go off-line for
a year, but as long as I can find all the patches that were sent in that
year when I go back on-line, it's ok.  Well, I have to figure out the
order to apply the patches in, but that's just a matter of code.

> But before we do all this, I'd like to understand
> whether the base p2p model is actually plausible.
> The minimal-context discussion has been going a
> bit over my head...

I think it's another "just a matter of code", unless the n^2 complexity
really bites hard in practice.  What I'd be curious to know is whether
anyone really wants to build things this way.  Linux uses distributed
change control, but there are still well known repositories, which I
think you really need, if only for integration.

Andrew
Permalink | Reply | 0 comments |

Gmane