[darcs-users] [patch39] Refactor Darcs.Commands.Pull (and 1 more)

[Nicolas Pouillard]

Excerpts from Eric Kow's message of Wed Nov 04 15:13:17 +0100 2009:
> I'm going to abuse this prefixing trick I picked up from Trent and hope it
> doesn't just make things harder to follow...
> 
> kowey>> It seems to share the sort of conceptual integrity that (IMHO) makes
> kowey>> Darcs so nice to use.  It does add a bit more symmetry too
> kowey>>
> kowey>>     get   / put
> kowey>>     pull  / push
> kowey>>     fetch / send
> 
> twb> I thought apply was the "complement" of send.
> 
> Depends on what perspective you're taking.  Yes, in a sense, apply is the
> complement of send in that what people send, you apply.  But what I was saying
> is that a fetch command would add a complement with respect to the direction
> that patches flow.
> 
> For those of you that actually like using fixed-width fonts for email, let me
> try to convey the idea with a cheesy ASCII art table.
> 
>  ------+-------------+-----------------+---------------------
>        | source      | context         | result
>  ------+-------------+-----------------+---------------------
>  get   | remote repo | none            | new local  repo
>  put   | local  repo | none            | new remote repo
>  ------+-------------+-------------- --+---------------------
>  pull  | remote repo | local  repo     | updated local  repo 
>  push  | local  repo | remote repo     | updated remote repo
>  ------+-------------+-------------- --+---------------------
>  fetch | remote repo | local  repo     | bundle
>  send  | local repo  | remote repo     | bundle (+ email)
>  apply | bundle      | local  repo     | updated local repo
>  ------+-------------+-------------- --+---------------------
> 
> The idea here is that yes send/apply are complements if you focus on
> source/result, but if you focus on source/context, then you want something like
> send/fetch.
> 
> OK but then Ian and Florent would also say that the distinction between bundles
> and repos is rather silly.  You can really just think of a bundle as a lazy
> repo.
> 
> In that light you might just be able to think of replacing send/fetch/apply
> with put/get/pull (adding aliases as needed).  Then again, that might be
> awkward because put/get don't get have a notion of context...
> 
> kowey>> Ganesh pointed out is that we can then explain pull as being fetch +
> kowey>> apply
>  
> twb> hg and git have this distinction, and I really hate it.  It means that
> twb> there are, in effect, two kinds of pull operation, and when the combined
> twb> fetch-and-apply operation fails, I don't know if I'm supposed to use the
> twb> fetch operation and then somehow manually resolve the problem
> twb> (conflict?), or if there's something actually wrong with the network.
> twb>
> twb> I routinely throw away my hg repos and re-record the changes against a
> twb> fresh clone, because it's too hard to work out what I'm supposed to do
> twb> next in order to stop the fetch-and-apply operation bitching at me.
> twb>
> twb> Maybe Darcs can do better, but I'd like to see the use case for fetch.
> 
> Excellent, fight feature creep!
> 
> kowey>> Finally: another option to consider would be to implement darcs plugins:
> kowey>> http://bugs.darcs.net/issue1504
>  
> twb> So then Darcs ends up like firefox, where you can't get anything done
> twb> until you install half a dozen of your favourite plugins? :-)
> 
> stephen> You mean like Bazaar, where essential functionality is hidden away in
> stephen> experimental plugins in developers' private download areas. :-(
> 
> Well the idea is that new features could begin life as plugins and after some
> time make their way into Darcs proper, say, after 6 months.

I think there two kind of plugins:

* Mercurial ones are plugins in traditional way, they are just modules (not
  commands), reusing the core library and loaded by the main system.

* Git ones are more UNIXy, first you have separated commands git-foo, they are
  maybe hidden in some libexec directory, they may reuse the core library (or
  not), and they are spawned by the main command.

IMHO real plugins tends to turn your project into something much more complex
than needed. I would prefer having, a core library, a set of commands, and a
main command to polish up.

Best regards,

-- 
Nicolas Pouillard
http://nicolaspouillard.fr