the current development branch (> 1.17; revision 4559) of GNU Bazaar
(http://bazaar-vcs.org) supports Tahoe LAFS as storage backend.

Here's how to set it up:

   1. Install GNU Bazaar > 1.17:
      bzr checkout lp:bzr; cd bzr; python setup.py install
   2. Enable Tahoe's FTP frontend as described in
   3. Create a new Bazaar repository (optional):
      bzr init-repo --1.9 --no-trees ftp://u...@localhost:8021/
   4. Create a new branch:
      bzr init ftp://u...@localhost:8021/my_branch
   5. Checkout:
      bzr checkout ftp://u...@localhost:8021/my_branch
   6. Add files
      cd my_branch; touch testfile; bzr add testfile
   7. Commit:
      bzr commit -m start

Common problems:

    * bzr fails with "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii'
      codec can't decode byte 0xe4 in position 5: ordinal not in range(128)"

      Bazaar tries to determine the local user name if it is not part of
      the FTP URL. If the name contains special characters like umlauts,
      bzr fails with this error message. Solution: specify the FTP login
      as part of the URL: ftp://usern...@host

    * Large pushes (uploads of several revisions) are very slow, bzr
      warns that "FTP server does not support file appending natively.
      Performance may be severely degraded! (502 Command 'APPE' not

      Due to the limited command set of the Twisted FTP server, file
      appends have to be done on the client side. This means that the
      current write group is downloaded and reuploaded (with the next
      revision appended) for each revision in the current push. You can
      probably work around this problem by preparing a suitable branch
      locally and uploading it using an ordinary FTP tool.

    * bzr warning: "FTP Could not set permissions to 0700 on
      /my_branch/.bzr. 502 Command 'SITE' not implemented"

      File permissions are not preserved, but that doesn't really matter.

    * Ineffective file locking

      Protection against concurrent writes is achieved through lock
      files, which does not work reliably with Tahoe AFAIK. Bigger teams
      with a shared branch should probably therefore employ an automatic


    * "SCM in the cloud"
          o central repository without a central server
          o inherent backup

    * secure storage
          o only team members have access to the files (IT staff doesn't)

    * granting read-only access is easily possible (via read caps)

    * (non-bzr) access possible via all available Tahoe frontends: HTTP,
      S/FTP, CLI, ...



tahoe-dev mailing list

Reply via email to