Jian Cha Research

Table of Contents

  1. jiancha (检查)
    1. Concept
    2. Goals
    3. To do list
    4. Code Name
      1. jiancha
  2. Requirements
    1. Interface Requirements
      1. Automated Submission
      2. Per change review commentary
      3. Suggested modifications
      4. Viewing change context
      5. Multiple attempts per review
    2. Business Requirements
      1. Criteria for Automated Committal
      2. Follow up committal
      3. Suitable review trail
      4. Repository Abstraction
    3. Technical Requirements
      1. Changeset Storage
  3. Functional Specifications Document
    1. Review Commentary
    2. Review Process
    3. Rules Engine
  4. Jian Cha Research
    1. Code Review Research
    2. Code Review Systems
    3. Subversion access
    4. Repository Abstractions
      1. Properties
  5. Outlying System Design
    1. Design Goals
    2. SCM Abstraction
      1. SCM Interface
      2. Subversion Abstraction
    3. Shelving
      1. Shelving changesets in subversion
    4. Rules Engine

Code Review Research

We already know reviews are useful, but other people have written about why.

Code Review Systems

This idea has been brewing around here for years, but it's been done a number of times before. Some attempts resulted in unsatisfactory code, others are proprietary and some such as Google's are simply dependent upon the wrong technology.

The goal here is to attempt to remain as abstract from the repository as possible, while tying directly into the trac framework making the assumption that trac is being used for issue tracking, among other things. This will allow cross referencing between documents (issues, wiki pages, changesets, etc) in the trac system.

The eventual goal is to build and/or use trac-integrated solutions to solve the majority of problems faced with managing software projects.

Open alternatives:

  • Code Striker Seems to be a pretty weak project, with an archaic interface and limited if any integration.

Commercial Alternatives:

  • Code Collaborator This is actually a pretty nice system, which largely reflects some of the goals of this project. It lacks automated submission of approved code, and appears not to integrate well with anything other than perforce.

Subversion access

Currently the subversion python bindings are totally undocumented. I was however able to find some information about the api here. Also, after looking at those notes (despite how misleading the binding code and tests were) I discovered that the python svn swing bindings do in fact have sufficient support to open a pending transaction, acquire data from it, and etc. The C documentation is the only form of sufficient documentation. The following are things I have noted about it.

  • The swing mapping makes a direct translation from C to Python. svn_fs_list_transactions() becomes svn.fs.list_transactions()
  • The first argument if the C api typically becomes the return value in python, as expected.

Currently exists a nice, but quite insufficient, abstraction of this API labeled pysvn. It's entirely inadequate for direct repository access and lacks the ability to create and commit a transaction. It also lacks write streams (at least).

Repository Abstractions

Currently exist, available in python, a few different repository access abstractions. They however seem to focus on read only access and are thus insufficient for this project. The system jiancha will plug into, trac, even has it's own. The trac abstraction only provides read access at the revision level. Also exists one called Branches which is a client only abstraction which only has API support (if you want to call it that) for working copy actions.

Jiancha is in need of an abstraction which will allow transaction level and revision level access including the ability to create a complete changeset from scratch. At the time of writing, this seems to constitute creation of a full fledged abstraction to for direct repository access.

Properties

This is just a note regarding the subversion properties use for enforcement of specific subjections of the repository requiring (or not) review. Given that properties and other file meta-data is not a common feature among various SCM/revision control systems (although certainly more of them have them than not these days) it should be abstracted. This means that the rules engine will have to access these properties itself as a part of it's rule enforcement passes, and atleast some component of it will need direct access to the subversion repository and API.

This however sort of trumps the existing proposed data access model, but may be a necessary sacrifice.

Alternatively, it may be possible to include properties as a part of the abstraction but, similarly to transactions, require that implementors build them separately of the SCM if they are not inherently present.