Hey all, Some technical details about upcoming work which might interest the list.
I had sent a message to apologise for slow work on a job I had promised to do, and also to ask some questions re: minimal_context. Juliusz answered and it was very helpful :-) Thanks, -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
--- Begin Message ---[CC-ing Zachary and Tommy, who might want to hear. I really think that D-U or D-D are better forums for this sort of discussion, but that's up to you.] > At FOSDEM, I had promised an implementation of minimal_context. > I am sorry to report that I am very much behind schedule darcs-wise > and am not look very likely to catch up. Don't worry -- so am I. My plans are, in rough order of precedence, (1) hashed inventory format; (2) patch tracker (with Zachary Landau); (3) end-to-end validation; (4) rework Darcs-Git David style. I'll only need the minimal contexts stuff for (3), and I don't expect to work on Darcs (beyond day-to-day maintenance) before the end of the month. > Besides, I understand that part of the point is that this job is > easy and thus a good vehicle for spreading darcs knowledge beyond > the "core" developers. No, it's not -- it requires fairly good orientation within Darcs. > But I have recently been focusing on my thesis and have drastically > reduced my darcs hacking time. Familiar feeling... > A hashed context would be nice, but > because of commutation, you can't guarantee that that everybody's > context looks the same. So we calculate a canonical context for each > patch, that is, the minimal one. Do I have the right idea? Yep. > minimal_context :: PatchSet > -> Patch > -> (PatchSet, Patch) Yep. > Why is the context represented as a PatchSet, i.e. > [[(PatchInfo, Maybe Patch)]], > and not just something like [Patch] or even [(PatchInfo,Patch)]? It's not [Patch] because NamedPatch is not lazy enough. A PatchInfo can be computed by just looking at the inventory, while computing the Patch requires all of the patch to be read to memory. And the Maybe is necessary for partial repositories, which only have PI's for the missing patches (derived from the inventory), not full patches. > And for that matter, why is PatchSet represented as a list of lists? > I gather that it has something to do with tags, for example, maybe > that each sublist [(PatchInfo, Maybe Patch)], but I really am not > sure at all. >From PatchSet.lhs: -- A PatchSet is in reverse order, plus has information about which tags -- are clean, meaning all patches applied prior to them are in the tag -- itself, so we can stop reading at that point. A tag is clean when it contains all the patches that precede it. The last element of the element of a PatchSet is always a clean patch. Suppose that you're doing a pull. In order to find which patches need pulled, you start walking the remote PatchSet sequentially, making a note of every patch that's not available locally. As soon as you find a clean tag that's available locally, you can stop -- the magic of clean tags ensures that all the remaining patches are also available locally. Why is that interesting? Well, a PatchSet is constructed lazily (unsafePerformIO and stuff). Not touching the tail of a PatchSet avoids completely reading stuff of the network -- and hence downloading extra files in _darcs/inventories/. Hope this helps, Juliusz
--- End Message ---
pgp8p6z3aKvi4.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
