[GSoC] 4th draft for my application about api changes/enhancements

Ronny Pfannschmidt Ronny.Pfannschmidt at gmx.de
Fri Apr 3 03:52:12 CDT 2009


this one is the first one on
http://socghop.appspot.com/student_proposal/show/google/gsoc2009/ronny_pfannschmidt/t123874785090

-----

1. What project do you want to tackle?

I want to enhance api/gui support of mercurial in various ways.
This includes changes to the ui, the commands modules, error handling as
well as general external apis.


2. What design choices will have to be made?

* the important ones will be implemented
* the optional ones will be implemented if time allows

Important choices
~~~~~~~~~~~~~~~~~

* ui currently is a blocking reporter that is working in single thread
  it has to be extended to support reporting from a worker thread to the
main
  thread

* there is no concept of sets of tasks
  this makes reasonable progress/status reporting harder
  it's necessary to explore what steps certain operations do
  and how to extrapolate the current progress from that

* the effects of hooks on the ui is not clear
  there is need to explore how to make it work nice with concurrent
usage

* the repo apis have certain low-level aspects that aren't that helpful

  * `localrepo.status` is not enough, there is need for an api that can
iterate all
    workingfilecontext's in order to collect detailed status information
on the
    workdir

    * bzr's WorkingTree.iter_changes might provide a good starting point
for
      ideas

Optional choices
~~~~~~~~~~~~~~~~

* better commit building api for in-memory commits

  * builtin memory patch application (as done by bitbucket/thg)
    * patch interface
http://bitbucket.org/durin42/hgsubversion/src/tip/fetch_command.py#cl-179
        .. seems that iterhunks is not that wanted, mempatchproxy is

  * imperative commit building on top of the callback based memctx
  * generate merges + resolve conflicts without workdir (ie in bare
repos, possible uses for vcs backed cms/wiki)
  * how would an api look for adding merged files and/or merges to a
imperative ctx

* bundlerepo is one of the way to stack different kinds of repo's on top
of a
  existing repo, it might provide some nice effects to extend that
concept

  * explore stacked repos 
  * explore patch queues that dont need to be turned into revisions
  * explore better ways to use inheritance to combine different repo
types

* how does extensions.wrapcommand affect the api expectations

* how and where are plausability checks for commits helpfull and/pre
necessary
  * currently creating invalid repos is easy via the api

* how to extend repo more clean than patching self.class
  * collect mixins ?
    * select mixins based on capabilities/local capabilities

  * should there be a difference between local capabilities (repo
formats, workdir extensions) and 
    remote capabilities (wireproto, bundle formats, nested repos for
patch queues/subrepos)


3. What difficulties do you foresee? How do you plan to manage them?

* some of the hardships of the api are not inherently visible
  * creating simple api docs and trying examples will help to identify
them
* changes in the internal error reporting 
  are not supposed to change the output of the cli in any case
  * this is supposed to be handled by the integration tests
* the changes will deprecate the ways cutehg/thg/anyvc currently go,
  there is need for collaboration on how stuff will work 
  and how to manage the transition
* changes in error reporting might render the cli/generic split
unnecessary
* reporting might need some kind of thread awareness
  at least for async use in gui toolkits via background threads
  however this could be deferred to ui subclasses targeted at the
specific ui toolkits/applications


4. What intermediate milestones can be defined?

 # each milestone needs a short documentation phase
 # each milestone lists something that will be of interest for api users
 # the order of main items is yet to be decided

* repo usage

  * thread safety ?
  * status -> change + rename iterator
  * differences to remotes (ie incoming/outgoing for nodes +
tags/bookmarks)

* exception introduction

* ui usage

  * tread safety
  * reporting to ther threads
  * waiting for user interaction in other threads
  * progress reporting
  * various util modules

    * command
    * cmdutil
    * hooks

* in memory api's
  * imperative commit 

     memctx is callback based
     something should sit on top of that giving api users a easy way to
add
     changes to a context

  * merge-resolve
    .. not yet clear

  * patch application
    * steal from tortoise/bitbucket
    * can patch queues be viewed as set of applied patchs on top of the
repo
      * semilar to bundlerepo


5. Who are you?

My name is Ronny Pfannschmidt, and i'm a cs student in Germany.
I'm a core developer of the pida ide and the main author of the anyvc
vcs abstraction library.
My prior experience with mercurial is using it from cli as well as the
api (mainly in anyvc),
I contributed a minor patch to fix a bug in the export command.






More information about the Mercurial-devel mailing list