Progress with Cart:

Aaron Bentley aaron.bentley at utoronto.ca
Thu Oct 11 21:59:13 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Radim Kolar SF.NET wrote:
>> I've made a lot of progress with Cart, the Trac alternative I've been
>> working on.
> What are problems with Trac, except that is unmaintained and important
> bugs are not fixed? We are using trac+bzr daily.

As am I.

There are two major issues with Trac
- - its architecture is a poor match for Bazaar
- - it doesn't support our workflow well.

The second one is somewhat a matter of taste, but it's a significant
factor for my company, because it reduces the usefulness of Trac to us.

Perhaps some of these issues could be addressed using plugins, but for
us, the architectural issues mean that's not worth pursuing.

Architectural issues
====================

- -Follows Subversion's behavior in making no distinction between the
branches in a repository, and the files present in those branches.

- - Assumes the basic unit is the repository.  In Bazaar, the basic
unit is the branch-- repositories are just clouds of revisions and their
location and scope is irrelevant.  A project may be spread across many
repositories, or in the other extreme, it may be contained in a small
portion of a much larger repository.  trac+bzr addresses this by
pretending that an arbitrary directory is a repository, and treating
both branches and directories within that repository as repository contents.

- - Assumes that it is cheap to determine the last revision to modify
any of the children of a directory, recursively.  This is not true in
Bazaar.  Providing the correct answer to this query is quite expensive.
 Plenty of people have complained about trac+bzr's speed as a result.

- - Bazaar repositories can contain plain directories that are not part of
a branch.  And so, Trac wants to know the revision that last modified a
plain directory that was not part of any branch.  This forced me to use
a pseudo-revision called "current:", which meant it showed up in in the
timeline view, which everyone hated.

- - I wanted to use 'path-to-branch' + revno as a changeset-id, because
these are unique, and much nicer than revision-ids.  But Trac
interprets slashes in changeset-ids, which meant that I could not use
the raw path-- I had to url-encode these paths, making them considerably
uglier.  People hated that, too.

- - Trac has a tendency to ask the wrong questions.  It would ask for the
tree-shapes of two revisions and then compare them.  This is much more
expensive than just asking bazaar to compare the tree-shapes of two
revisions, especially considering how expensive it is to determine which
revision last modified any child of a directory.

- - The documentation was also poor.  And there was no information about
profiling that I could find.

Workflow issues
===============
- - Doesn't view projects as being composed of subprojects
- - Doesn't allow tickets to have dependencies on other tickets
- - Doesn't allow tickets to have a priority assigned to them, in the
  sense of an order than the tickets should be resolved in.  What Trac
  calls "priority", I would call "severity".

> Do you have plans to include Wiki too?

I've been convinced that Cart should integrate with a wiki.  I'm not
convinced that the right way to do that is to have its own wiki
implementation.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDo6g0F+nu1YWqI0RAp3eAJ0cphOcWcKd1H80DzJQ9pDZ6aYBlACfYDE2
NSgMXu4cg8k35CmGEkoWdiA=
=Rqrn
-----END PGP SIGNATURE-----



More information about the bazaar mailing list