start
Table of Contents

Version Control

Version control and networking / distribution are important topics for Pootle / Wordforge. This particularly relates to the ‘file server’ and ‘distributed translation management’ aspects.

For instructions on the current abilities of Pootle, see version control.

Needs

It would be great if Pootle could handle the following:

If we break down the needs, they tend to fall into two parts - workflow, and distribution

Workflow

Distribution

Two cases:

Pootle servers have a further two cases:

Proposed plan

Xliff already has scope for handling multiple translations of strings etc, we should use this for workflow. On the other hand, its good to keep a full history as well. But storing per-message history in a version control repository might be overkill (especially if we don’t need it).

For example, once a work cycle is complete, we could commit the current Xliff with all the proposed strings and their resolutions. When a new work cycle starts, we could start dropping the strings from the previous work cycle for any strings that are changed. So at the end of the new work cycle, any unchanged strings will retain their history from the previous cycle, but changed strings will contain just the current work cycle’s history. At the end of the new work cycle, we commit again to the repository... This way we always have a file with VC info and we can get more from the VC server.

This would give us no data loss (we can get the full history for any work phase by retrieving the last version), and hopefully simplicity in the current storage.

Using Xliff for workflow as its intended also fits well into the general Wordforge philosophy...

For the underlying version control, we could use something like bzr or Mercurial.

The design here needs to be tightened up somewhat...

Requirements for upstream version control

It may be easiest to require the person with upstream commit rights to have a local Pootle installation (so they can use their login details etc). In this case that scenario needs to be well thought through...

Requirements for offline scenario

Requirements for live server-to-server talking

Rights in a distributed setting

We need:

Further investigation

We also need to decide how much of this is overkill :-)

Possibilities

Considerations

Technology

Currently we call the command line programs, but there are alternatives:

CVS

There are two modules call PyCVS - http://software.cnx.rice.edu/downloads/python/pycvs/ which is a wrapper to the CVS commandline, and http://pycvs.sourceforge.net/ which is an implementation of the CVS protocol. There is also an implementation like this in the Python Demo directory.

SVN

http://pysvn.tigris.org