[darcs-users] Getting a full diff for pulled patches

[David Roundy]

On Thu, Jul 26, 2007 at 12:14:27AM +0200, Alexander Staubo wrote:
> On 7/25/07, David Roundy <droundy at darcs.net> 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.

A local partial get is much slower than a local full get, or at least it
should be.

> 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.

This is assuming no conflicts, replace patches, etc.

You could also get the remote patch contents with darcs changes --repo -v.

> 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.

You could also just process the output of darcs annotate on the file to
remove the annotations.  It's a bit stupid, but allows you to use darcs to
get the version of the file you want.

Or if you really just want diffs, why not use darcs diff? Or darcs annotate
--unified?

> >> 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.

Okay, there are other applications that are willing to communicate with the
interactive darcs prompt, and I had assumed yours was one of those.

> 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.

Again, if you pull once into a scratch repository, this will be fast (as
far as bandwidth goes).
-- 
David Roundy
Department of Physics
Oregon State University