[darcs-users] Re: questions on development process

David Roundy droundy at abridgegame.org
Tue Aug 10 11:14:30 UTC 2004


On Mon, Aug 09, 2004 at 07:11:23AM -0400, Eric S. Johansson wrote:
> David Roundy wrote:
> 
> >On Sun, Aug 08, 2004 at 09:44:49AM -0400, Eric S. Johansson wrote:
> >
> >>I will experiment with that and see.  I was also thinking about
> >>automatic triggers for updating the repository whenever I tag it for
> >>release but it's probably not a good idea.  but maybe adding rsync as
> >>an option for pushing.  On the other hand, my earlier suggestion of
> >>separating the communications functionality from darcs could make
> >>adding new forms of repository propagation easier.  It also might
> >>simplify darcs by allowing you to merge push/send as well as pull/get.
> >
> >Interestingly enough, originally push and send *were* the same command
> >(called push), but that confused people enough that I was finally
> >convinced to separate them!  :)

(a slight aside...)

As far as abstracting the communication goes, that's why I originally had
push and send be the same command.  The problem is that there is a
fundamental difference between a synchronous communication channel and an
asynchronous channel.  In the former (i.e. direct file access, ssh, etc)
it's possible to say "the push succeeded, and now the patch is in the
target repository".  But in the latter (email, create a file and let the
user send it on floppy disk via US mail), darcs has no way to guarantee
that the patch will ever be applied.  Using the same command for both sorts
of action is confusing, especially since there are options (such as
--no-test or --test) which apply only in the synchronous case.

> >As far as the idea of merging pull and get, I'm not too keen on it
> >(which doesn't mean I couldn't be convinced--I was dead set against
> >separating push/send, but was convinced in the end).  Get and pull have
> >such incredibly different memory use behaviors, internal algorithms and
> >usage situations that I don't see how it would really simplify things if
> >we merged them.  Having one command that does a dozen different things
> >all depending on the situation is confusing.
> 
> internals aside, from the "I'm learning darcs and here's a brick I 
> tripped over" perspective, the only difference between pull and get is 
> that one seems to be for local repositories and the other for remote. 
> and for the most part, the only difference there seems to be the 
> communications method.  As for send and push, the only differences I see 
> also boil down to how you push (i.e. communications method).
> 
> this is why I'm thinking the two groups of commands could be merged. 
> Now if there obviously doing different things, then they should be 
> separated but not if the difference is strictly communications based.

As Dustin said, the difference between get and pull isn't the
communications method (as both of them can use any communication method
darcs supports), but rather what they do.  get creates a new repository (or
you might call it a new copy), and pull updates an existing repository.
The difference in memory behaviors I mentioned comes from the fact that
creating a copy of a repository is "easier" than updating an existing one
(where there might be conflicting changes, etc).

I suspect this misunderstanding indicates an inadequacy in the
documentation, perhaps in the getting started section?
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list