[GSoC] 2nd draft for my application about api changes/enhancements

[Ronny Pfannschmidt]

Am Mittwoch, den 01.04.2009, 17:20 +0200 schrieb Ronny Pfannschmidt:
> Hi,
> 
> i pretty much collected various nagging points of different users of the
> api.
> 
> Some parts are vauge (most notably the changes for commands/error
> reporting) as i need to work with the api in order to figure a good way
> to do it.
> 
> Other parts are research questions that require further investigation in
> order to make the api as save and unambigious as possible.
> 
> Please comment.
> 
> Regards Ronny Pfannschmidt
> 
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
-------------- next part --------------
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?

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

* there is no concepts of sets of tasks
  this makes reasonable progress/status reporting harder
  its necessary to explore what steps certaion 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 lowlevel aspects that arent that helpfull

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

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

* bundlrepo is one of the way to stack different kinds of repos 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)


* 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

(Detail how you plan to implement the project. Explain data structures used or changed, compatibility issues, and trade-offs.)

3. What difficulties do you foresee? How do you plan to manage 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 defered to ui subclasses targeted at the specific ui toolkits/applications


(Where do you see potential problems? If you don't know, ask around on mailing lists or IRC.)

4. What intermediate milestones can be defined?

..  this needs reorganisation, sync with the "design choices" and deadlines

 # 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 savety ?
  * status -> change + rename iterator
  * differences to remotes (ie incoming/outgoing for nodes + tags/bookmarks)

* exception introduction

* ui usage

  * tread savety
  * 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

  * bundlerepo cleanup

(We need a few of these, so we can check up on your progress. You probably want at least three of these. Start off with some documentation, design options/trade-offs and include tests somewhere.)

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.