On Mon, Jun 01, 2009 at 10:49:11 -0700, Jason Dagit wrote: > I would encourage people to play with this. I strongly believe that darcs > should be a playground for people who want to do research into distributed > version control.
Rocky Kahn was once asking about patch types for XML files. It would be good if we could support this sort of experimentation, for example with a sort of darcs library that people could use with their custom patch types. A library would also be good for people who want to work on darcs GUIs, IDE integration, web interfaces, etc. There is a lot of work to do and we definitely need help from the community to make progress. Some things on the list: 1. Replace homegrown code with decent 3rd party code where possible (keep darcs small) 2. Spin general purpose darcs inventions out of the darcs code (keep darcs small 2: hashed-storage could be seen as an example, but I'll bet there's lots more we could break down) 3. Finish off the type witnesses work 4. Split library into core, repo, exe (and maybe more). Folks like Jason have been saying this for a while, and camp is doing this from the get-go; but it would be useful if we could make more concrete steps. 5. Develop a proper Repository API. This needs more darcs mastery on our part and thinking. Hopefully Petr's work on optimising darcs will give us a bit more experience to know what we need to do. 6. Separate user interaction from repository manipulation (The patchwork guys have something to say about this, I think) 7. Clean up handling of darcs flags http://bugs.darcs.net/issue1157 8. Develop some sort of Darcs monad? or other mechanism to keep track of darcs specific state? 9. Haddock everything. The Darcs library has a place on my internal roadmap. My hope is that once we get some of the big performance work in (improved hashed repositories, filecache), we can turn our attention more towards the library. I have some uncertainty about how camp/darcs-3 fits into this, but since we know that this is for at least another year and a half away perhaps more, we should probably operate on the assumption that we may be hanging on to the darcs code for posterity: i.e. keeping cleaning it up, documenting it, trying to develop APIs. In the best case, this gives us little libraries which we could then share with camp and darcs 3 (yay, saving effort). In the worst case, we learn things that we can then apply to darcs 3. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
