On 7/25/07, Alexander Staubo <[EMAIL PROTECTED]> wrote:
On 7/26/07, David Roundy <[EMAIL PROTECTED]> 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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
