> Summary: after looking at things I still prefer making the copy/link > discrimination in copyLocal (i.e. at the bottom level) and ensuring > that [DarcsFlag] is passed on down through all paths even though this > has the "splatter" effect on many functions.
Ok, as per your comments, your first two patches are going in along with conflict resolution. And since nobody else chimed in, I'll guess this was the right thing to do after all. > As it turns out, fetchFile and gzFetchFile are both used to read the > specified file into local memory, and if their argument is a file, they > will do so directly. Right > Thus, these paths never involve a link v.s. copy decision. I *could* > reduce the splatter a bit by not requiring [DarcsFlag] to be an > argument to fetchFile/gzFetchFile (internally supplying a null array to > copyFileOrUrl). that will probably bite us in the end, so I agree, no. > ** The [DarcsFlag] is really an environment (ReaderT monad anyone?) that > describes how darcs should work overall. Yeah, Tommy and I were discussing this a while back. ReaderT is probably good. We might also want to throw in a StateT for some other more mutable stuff. I think I had submitted a very rough DarcsIO monad for discussion. Would be nice if somebody worked on it :-) > > ... I was thinking that we could mirror the copy/clone distinction and > > have a function cloneFileOrUrl. ... > > Unfortunately, cloneX is used quite a bit in External.hs and it has > nothing to do with links, so at a minimum some other name would need to > be used. Well, what I meant was that clone would be specifically for copying files (as it is being used now) and copy would be for either copy-or-link (as it is being used now) -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
pgp5xAs1wTuXC.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
