On Tue, Apr 10, 2007 at 10:12:11PM -0700, Kevin Quick wrote: > IMHO, good question, Max. I had the same question, only adding > _darcs/prefs/repos as well. > > To amplify (at the risk of simply restating Max's comments): > > 1) A lazy, "not-here-yet" patch would not contain the url, just a > constant keyword (e.g. "NOTFETCHED"). > a) For that matter, why does it even need a file? The inventory > says it should be there, so if it's missing, it's just assumed > to be a lazy "not fetched yet" patch.
In any case, I'd like to leave a "paper trail" of the source at which the patch is expected to live, so that at a minimum we could give good error messages. Otherwise, users could (in some convoluted scenario involving greater degrees of laziness than have yet been implemented) potentially be unable to find out where a patch that supposedly in their repository was supposed to be located. > 2) When darcs *needs* to read that patch and sees NOTFETCHED, it > first tries to get it from _darcs/prefs/defaultrepo, and if not > found, it then iterates through _darcs/prefs/repos until the patch is > found or all is exhausted. > > a) In the latter case, darcs generates a message: > "Could not get patch 'xxx'; please darcs pull from a source > repo that contains this patch." > > b) When pulling from a repo, that repo might also just have the > NOTFETCHED version of that patch > > i) Perhaps darcs should also fetch > _darcs/prefs/repos from that repo and nub add it to > _darcs/prefs/lazyrepos, which is the third scan list for > finding lazy patches.... > > This helps sidestep the issue of "the source can never move" to a > degree, and if the source does move, a darcs pull from another repo that > has that patch makes them available again. I'd certainly not like to do this by default, as pulling from various repositories could have side-effects such as prompting for passwords to a whole slew of servers, which I'd rather not suprise the user with. However, as an optional feature, I agree that this would be a good idea. > 3) Also, perhaps commands like "darcs changes -v" that might ordinarily > need to fetch all the patches could instead (for a lazy repo), exit at > that point with a message like: > "[possibly more in remote source repos; use --fetchall for a full list]" > > That way, a user's normal work would only work with the patches locally > available (which they'd want, given that they'd gotten a --lazy pull), > and they would actively tell darcs that it was OK to possibly take more > time and fetch the lazy patches. > > a) Maybe the --fetchall is always required, and any command that > runs into laziness incompleteness would generate either > i) a standard warning (like above), > ii) an error, indicating that the option was aborted because a > NOTFETCHED patch was needed and --fetchall was not given, > iii) a message like Eric is proposing that indicates a fetch is > needed and asking if it's OK to do right now. > > Note that I like both --fetchall and an interactive response; the > former allows the directive to be given up front so that you're not > "surprised" by the different question (e.g. after answering y or n for > 47 patches on a pull, your n doesn't suddenly mean "no, don't fetch > from remote"), but the latter does allow you to only decide if/when it's > necessary. Your --fetchall flag (or maybe --try-to-download-missing-patches?) sounds like one that could complement lazy repositories (or perhaps convert partial repositories to effectively lazy ones). We already have code in darcs changes to properly support partial repositories, so nothing there would need to change. I think the two approaches complement each other: --lazy allows you to specify when getting a repo that you'd like to delay downloading of patches, and then you don't need any more configuration to download them later, and you also won't end up with darcs trying to log into a top-secret server to grab these patches. The --fetchall flag (--fetch-missing?) would allow configuration such that darcs will automatically search for missing patches (or perhaps even patches that fail the checksum?), which is a bit easier to use, and could potentiall work in trickier scenarios, where the original repository disappears. But which has the disadvantage that you could potentially end up being unexpectedly prompted for your password, which seems like a security-scare scenario. i.e. you shouldn't generally type a password unless you expect to need to type it, and know why you need to type it, and I don't like darcs perhaps incorrectly prompting you for a password. It's just asking for a clever phishing scheme, if users get accustomed to this (or if we tell them that it may be normal). -- David Roundy Department of Physics Oregon State University
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
