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

Eric Kow kowey at darcs.net
Wed Nov 4 14:13:17 UTC 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.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20091104/adc5d435/attachment.pgp>


More information about the darcs-users mailing list