On 7/25/07, David Roundy <[EMAIL PROTECTED]> wrote:
Locally cloning is pretty fast (should be blinding [...]
Hm, I don't think so: $ time darcs get --partial trunk trunk.test Copying patch 2153 of 2153... done. Applying patch 2152 of 2152... done. Finished getting. real 1m12.621s user 0m20.628s sys 0m15.593s This is a small repo -- 3,500 files or around 24MB in total (excluding _darcs, which has 5,600 files, or 64MB). Perhaps this operation is fairly quick with recently-checkpointed repos, but I can't count on this being the case; the operation I am implementing cannot take more than a second or so. Actually, my question is similar to the FAQ (asked just recently on this list) about how to retrieve a specific version of a file. Given a patch -- specifically, one that can be pulled from a remote repository but has not been applied yet -- I want to obtain the file it can be applied to.
From what I can tell, I can accomplish this the following way: (1)
Read the current pristine from _darcs/pristine. (2) Run "pull --dry-run --verbose --matches=...". (3) For each patch minus the patch I actually want, take each hunk and apply it to the file. Hunks are simple enough to parse that I can apply them directly without going through Darcs. The end result, as far as I can see, should be the ancestor of the patch I want. I think I can be able to detect conflicts this way, too. The actual case I want to solve is when pulling a bunch of patches from another repo. I want to display each patch individually to the user, showing the original file before it was changed. To do this, I use the algorithm above, but because I'm processing multiple patches against multiple files, I maintain a separate working files (one per file per patch) internally that I apply the hunks to. The process for push is similar, but I need to use "darcs changes" instead to build up the original file; in fact, I guess I can skip the read-the-pristine-file step and simply use the --to-match argument to get the entire change history.
> Absolutely. Darcs does not supply this dependency information, > unfortunately. Some trickery with "pull --no-deps" might be used to > detect dependencies. You can do simple things by using 'w' (or 'j') instead of 'n' if you want to pull a patch only if it's required by another that you say 'y' to later. In fact, if you choose, you can extract (almost?) all the patch dependencies from a single call to pull, by judicious use of 'y', 'n', 'w', 'j' and 'k'. The only catch is that the dependencies of the last patch are tricky to get, since if you say 'y' to that patch, darcs immediately starts the actual pull.
I take it you did not read my original message. :) Darcs is actually being invoked non-interactively here, by an application; the app drives Darcs, parsing its output. I will not attempt to communicate with the interactive Darcs prompt, I think -- it will be too brittle. I think that the only reliable, programmatic way of detecting dependencies is to run "darcs pull --dry-run --matches=..." on each individual patch name. Of course, this will not let me build an exact graph of dependencies, but I don't need that. The problem with this approach is that it is going to be very slow with remote repositories. Alexander. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
