Trent W. Buck wrote: > Eric Kow <[email protected]> writes: > >> It seems to share the sort of conceptual integrity that (IMHO) makes >> Darcs so nice to use. It does add a bit more symmetry too >> >> get / put >> pull / push >> fetch / send > > I thought apply was the "complement" of send.
As Eric said, fetch is the symmetric of send (it's the same action, but initiated by receiver), while apply is what the receiver does after a send. > >> Ganesh pointed out is that we can then explain pull as being fetch + >> apply > > hg and git have this distinction, and I really hate it. It means that > there are, in effect, two kinds of pull operation, and when the combined > fetch-and-apply operation fails, I don't know if I'm supposed to use the > fetch operation and then somehow manually resolve the problem > (conflict?), or if there's something actually wrong with the network. This is already the case in darcs. Except that you either have to give up right away or, if you want to investigate whether it's network trouble, try to _get_ the remote repository and then do the merge manually using local pulls. I'm not sure making investigation of problems harder qualifies as a a good way to solve them. Note that contrarily to hg fetch (and probably git's equivalent), *darcs fetch is a no-op as far as the local repository is concerned*. So it can't make anything harder, only give you more information to work with should you want to. > > I routinely throw away my hg repos and re-record the changes against a > fresh clone, because it's too hard to work out what I'm supposed to do > next in order to stop the fetch-and-apply operation bitching at me. > In that respect, darcs fetch won't change anything. > Maybe Darcs can do better, but I'd like to see the use case for fetch. > Darcs _is doing_ better: fetch is a /pure/ operation! My use case was "merge on the train": i have a small set of private patches which i want to merge by amend-recording out any conflicts (semantic or syntaxic). Then I want to fetch the remote repository straight away, and apply the bundle patch by patch on the train while doing the amend-record, so out of net-connectivity. Especially, if i want to read the patches (as we like to do when they get sent to the list), it is more comfortable and lightweight than doing a local pull into a fresh repo, then using pull between the two local repos. The other reason is so that I can do a quick fetch of a few patches from a university machine to put on my usb key so that I can apply them at home where the machine is unreachable. This is a case where having a The third case is if I want to choose now what patches I want to ultimately apply, but I want to apply them cautiously later, then I can divide the mental load by first fetching then applying, without having to create once more a fresh local copy from which to pull. Maybe also they can allow Eric to send patches to the list on behalf of a shy/missing developer who does not want to/cannot send, but only be pulled from. (There might be ethic problems with that one…) Finally, maybe I want to keep some foreign repo as an archive for myself, but don't see any point in applying it (but there might be at some point, or maybe i want to keep it along with an explanation as to why it's not mergeable). In that case, a bundle is much more reasonnable than a full repo (either for mailing to myself or keeping on a usb key). Fetch allows you to use bundles as lightweight no-working-dir repositories, which are very useful in some workflows. This is because it makes treatment of bundles symmetric with respect to local/remote ,which is arguably simplifying the command set. And i have much less problems with having stale bundles lying around rather than stale whole repos. > Hm, I don't suppose you could simply express it as pull --dont-apply or > --no-working-tree, similar to push --no-working-tree (for pushing to a > "dumb" remote host which lacks Darcs)? It could be called pull --dont-apply -O if you really want to avoid new commands. But given the symmetry with send, i find it much better to have a new command rather than an option which changes so radically the behaviour of pull. I think darcs pull -O is the bad kind of options, where adding -O changes the post-condition of pull. Currently, only --dry-run (and --xml-output ?) changes the post-condition of a command, and I think it is something that makes darcs simple to understand and easy to use. Florent _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
