[darcs-users] Which google SoC 2007 projects were done?

[Eric Y. Kow]

Ah! I didn't even know that page existed.

I have updated the wiki with what I know (which may not be accurate).

In the interest of generating discussion, here is the list with my annotations.
If you have any corrections to make, please propagate them to the wiki

* A Windows project: not sure what this would entail, but darcs on Windows
  might need a bit of special attention
      o 2008-06 : proposed as a priority for darcs 2.1 
* Darcs edgewall trac integration. This is a hybrid project that would probably
  be mostly python, and would properly speaking be a trac project, but would be
  very helpful to darcs, and primarily related to darcs. Ideally should also
  support working with multiple branches / multiple repositories transparently.
  See also http://trac.edgewall.org/wiki/VcRefactoring, and
  http://trac.edgewall.org/wiki/GoogleSoc2007.
      o 2008-06: See TracOnDarcs (single repo only) 
* Darcs roundup integration. This is a hybrid project that would probably be
  mostly python, and would properly speaking be a roundup project, but would be
  very helpful to us, and primarily related to darcs. It's open-ended in scope,
  but would probably include automatic closing of issues by in changelogs,
  tagging issues with which versions (in terms of something darcs-readable like a
  changes --context) display the bug and which don't, and perhaps some mechanism
  for users to query bugs that affect their version of darcs. Ideally should also
  support working with multiple branches transparently.
      o 2008: Done by Mark Stosberg 
* A single-file database pristine cache, which should be faster and more robust
  than our directory-based approach. e.g. a halfs filesystem.
      o 2008: darcs 2.0.0 has hashed pristine, which is more robust, but it's
        not single-file. do we still want this? 
* Keeping track of which patches affect which files, to speed up query
  operations that affect only certain files (e.g. changes, diff, etc, when
  given a filename argument).
      o 2008-06 status: I don't think we do this yet. Still open? 
* Move darcs to use Data.ByteString.Lazy instead of our own FastPackedString.
  And perhaps throw in some optimization and benchmarking.
      o 2008: Eric and Gwern have done some work to use ByteString, although I
        think it's the just the standard strict one for now 
* A benchmark suite for darcs. Possibly make it version-control-system
  independent, so we could have automated and meaningful performance benchmarks
  against competitors? Would need to be flexible to simulate real workloads and
  automatically generate real repositories.
      o 2008: See http://code.google.com/p/maybench - very very early in
        development. Needs volunteers 
* Develop a new binary patch type that is more efficient in space and time.
  Again, requires some sort of benchmarking.
      o 2008-06: still open? 
* Add support for a character-based hunk patch type. May require tuning of the
  LCS algorithm, if we want this to work for large files.
      o 2008-06: still open 
* Other interesting new patch types.
      o 2008-06: still open and untouched 
* Gui support. Eric's done some work on the wxhaskell gui, but there are
  locking issues with his current code, and it could really use an overhaul. This
  would be a problem where the student would need to propose a quantifiable goal.
      o 2008-06: note that Eric's code has now been removed from the repository
        (since he could not maintain it) 
* Conflicts work?
      o 2008-06: done for 2.0.0... maybe some more to do? 
* Git backend support?
      o 2008-06: still open 
* GADT existential phantom witness types. We have the idea--which has been
  pretty well worked out--of how to use witness types to enforce proper (safe)
  manipulation of patches, but there's the large project of putting this into
  practice. It'd probably require someone of Ian or Ganesh caliber to mentor, and
  a very serious and experienced Haskeller as the student. But it's definitely a
  major code improvement (incidentally, gaining no new functionality) that
  requires a lot of time, and will be extremely cool.
      o 2008-06: in progress... Jason and David have done the bulk of this, but
        not all our code uses it yet, if I understand correctly

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080529/2dbd0fa3/attachment.pgp