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

[Jason Dagit]

On 7/25/07, Alexander Staubo <alex at purefiction.net> wrote:
> On 7/26/07, David Roundy <droundy at darcs.net> wrote:
> > On Thu, Jul 26, 2007 at 02:32:22AM +0200, Alexander Staubo wrote:
> > > I didn't know this. All right, good point, though there's the
> > > additional snag: You cannot "get" from a partial repo -- you get this
> > > obscure error ("openBinaryFile: does not exist"), and you have to add
> > > --partial. So while performance on full repos might be fine, partial
> > > repos would be horrible.
> >
> > Hmmm.  This should be fixed.  There shouldn't be (in the sense that there's
> > no fundamental problem with the idea) any trouble with fast local gets from
> > a partial repository (which would result in a second partial repo).
>
> I agree. (The worst part really is the error message.) The bug entry
> for this issue has been open since January:
> http://bugs.darcs.net/issue392.
>
> > > What would have really helped is if "annotate" could support the
> > > --repo argument for remote repos. Then I could trivially reconstruct
> > > the ancestor file for both pulls and pushes, and it would all be using
> > > Darcs itself instead of my home-brewed patch reconstruction logic,
> > > improving future compatibility and reducing the possibility of
> > > unforeseen edge cases.
> >
> > Indeed, and this would be nice to add, but could be disastrously less
> > efficient on remote repositories, since we quite likely don't have access
> > to the pristine cache.  On the other hand, we already support operation in
> > the absence of a pristine cache, it's just slow.
>
> By pristine cache, do you mean _darcs/pristine? Why can't Darcs access
> the remote repo's pristine files -- is it not a case of scping/catting
> it?

Yup, he means _darcs/pristine.  I think not all repos have a pristine
cache so you can't count on it.  And other times the permission bits
might not be set correctly on the pristine cache to allow it to be
viewed.

> Sounds like the absence of the pristine cache means it would be slow
> to reconstruct the file from scratch, but not terribly so -- mostly
> gunzipping the history of patches and applying them in-memory, which
> can all be done server-side, or does Darcs transfer all remote files
> locally to operate on them?

Darcs really only consists of the one darcs binary.  With the
exception of push (and maybe put) I think most (all?) of the darcs
commands operate purely locally (eg., change files locally but not
remotely, I'm not counting read access).  Push needs to apply the
patches and to do this it invokes an instance of darcs on the remote
end and tells it which patches to apply.  This allows people to place
a darcs repository in their ~/public_html and thusly host the project
for the world to get with darcs get (since no server side software is
required).  In this case they would then accept patches via email for
instance and then apply them that way.

HTH,
Jason