[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