Differences between revisions 24 and 25
Revision 24 as of 2010-04-18 15:20:00
Size: 5496
Editor: Pradeepkumar
Comment:
Revision 25 as of 2010-04-18 15:20:52
Size: 5504
Editor: Pradeepkumar
Comment:
Deletions are marked like this. Additions are marked like this.
Line 74: Line 74:
 Email: in3xes@gmail.com IRC Nick: inXs_ (freenode.net) Jabber ID: in3xes [AT] gmail.com (talk.google.com)  Email: in3xes@gmail.com
 .
IRC Nick: inXs_ (freenode.net)
 .
Jabber ID: in3xes [AT] gmail.com (talk.google.com)

Email: <in3xes AT SPAMFREE gmail DOT com>

IRC Nick: inXs_

About Me:

- Student at IIT in India. Mathematics is my major.

- Fan of C, Python, Haskell. You can find some of my small projects on Github. -

- Love solving mathematics problems by programming. Solutions for the problems in Project Euler. Solved in python.

- Experienced user of git. Comfortable with Bazaar.

- Find me on Twitter

Google Summer of Code-2010

I am interested in "Parent delta". I can also work on conversion tools. But I am mainly focusing on Parent Delta Plan.

A word about project:

Mercurial calculates diffs against previous revision rather than parent. In some cases this implementation is space inefficient, and it is more sensible to store deltas against parent. This project is about implementing Parent Delta Plan. This implementation changes the structure of revlogs, so wire protocol has to be extended to allow backward compatibility.

============================================================================

Proposal

TO DO(Tentative): Major:

  • Changes in revlog
  • Changes in wire protocol

Changes in revlog:

  • Change revlog structure, now it appends the next delta to existing data.This helps in reconstrfucting a revision at O(1) seeks. If

parent delta is implemented better compression can be achieved but, may have to compromise with number of seeks.

  • Current:Linear delta model

    • --> O(1) seeks to create any revision.

  • Parent delta model
    • ** I think this can be completed quickly, tonfa shared patches for this***
    • --> An intelligent algorithm to reduce number of seeks to reconstruct any revision.I think constructing revision is

  • not straight forward as it is now. It's not going to be linear.
    • --> Investigation about merge revision. --> Optimization, and investigation for better implementation(If possible). --> Continuous parallel testing.

Changes in wire protocol:

  • Changes in wire protocol to allow backward computability.
  • Implementation of changes according to old, new servers,client, repos.
  • Rigorous testing
  • Integrating with other's work.(Changeset discovery, Lightweight copies/renames)

About Me:

  • I am student at Indian Institute of Technology, Roorkee. I am currently pursing third year of 5 years degree, Mathematics as major. I

am a Linux enthusiast. Interested in open source. I have been learning C,Python. Some of my projects can be found on github ( http://www.github.com/in3Xes ). I have never got opportunity to contribute to open source. GSoC would be stepping stone for that.

  • I am project leader in IMG ( Information Management Group, IIT Roorkee, http://www.iitr.ac.in/IMG/ ), a group which manages intranet,

  • student databases, institute website. I have worked on PHP, Java in web development.

Contact Information:

  • Name: Pradeepkumar Gayam

    Email: in3xes@gmail.com

  • IRC Nick: inXs_ (freenode.net)
  • Jabber ID: in3xes [AT] gmail.com (talk.google.com)

Schedule:

  • I would start coding well before the schedule given in the time line. My final exams will end by May-15th. I can start working
  • rigorously shortly after exams.
    • Till May-15th(or 24th according to time line) I will be reading code, documentation, getting used to coding style, getting ready to
    start coding, little experimentation and stuff.

My plan of time allotment: Changes in revlog structure: [Total 3 weeks]

  • Parent delta model:
    • --> An intelligent algorithm to reduce number of seeks to reconstruct any revision.I think constructing revision is not

  • straight forward as it is now. It's not going to be linear.
    • [(It can take 1 1/2 to 2 weeks to bring it to working stage, Roughly around 5th-Jun)]
    • --> Investigation about merge revision. --> Optimization, and investigation for better implementation(If possible).

      • --> Continuous parallel testing.

        • [( I would finish testing and other work nearly in 10 days, by 15th-Jun)]

Changes in wire protocol:[Total 3 to 3 1/2 weeks]

  • Changes in wire protocol to allow backward computability.
    • [(For midterm evaluation, this may not be complete, but significant part of it)]
    • --> Implementation of changes according to old, new servers,client, repos.

  • Rigorous testing.
    • [(I will start testing shortly after mid-term evaluation, i.e., around 18th-July, would take a week to complete)]
    • Integrating with other's work.
      • [(Changeset discovery, Lightweight copies/renames). ( Remaining time, depending upon other students)]

Link to my GSoC application on bitbucket.org

CategoryHomepage

Pradeepkumar (last edited 2010-10-22 18:17:21 by mpm)