Advocating a Tighter Subversion Integration

Motivation

Trac is not a versioning system, but it allows developers to use one effectively.

Nevertheless, Trac has its own versioning needs for its data. That would be useful for managing attachments. That's also true for the Wiki page content in the current Trac and that would be true for any Trac object in the the TracObjectModelProposal.

If one takes for granted the underlying versioning system, why not use it for that task instead of having to implement an ad-hoc versioning scheme?

That would:

• provide better diffs than what we have now
• need a smaller memory footprint (each version of each wiki page would not have to be stored in its full extent, only the diffs)
• provide versioning for attachments
• enable the users to directly interact with the Trac content, instead of having only the Trac web interface:
  • they could edit the wiki content with a text editor, as they would do with a normal repository file
  • they could do some refactorings on the Wiki content (renamings, fixing some pervasive typographical error, etc.)
  • they could directly add attachments to Trac object

Another feature that would be possible is to redirect a Wiki page as being some actual file in the normal repository. For example, a wiki page containing the description of a given software component could actually be placed in the doc subfolder of that component. Keeping it closer to the source increases its chances to stay uptodate.

This Wiki redirection would be quite simple to implement: the content would be a TracLinks pointing to a specific file in the repository. Actually, that's similar to the TicketAliases idea (See ticket #xxx).

The same for attachments: any file from the repository could be said to be "attached" to a Trac object, instead of having to be uploaded in all cases. In the end, an Attachment and a File would really be the same thing.

Implementation

There would be essentially 2 ways to implement that integration:

• using a private area in the Subversion repository being trac'ed
• using a private repository

A private area

A top-level folder in the repository would be used by trac. This could be /trac, but that would be configurable.

There would be no point to deal with a Changeset saying WikiPage AbCdEf modified, beside the regular WikiPage edited event, except, of course, if that modification was done outside of Trac, by a direct modification and commit on the Trac files.

Deciding whether a changeset must be taken into account or ignored could be done very simply: each revision created by Trac could be remembered as such, in a trac_revision table.

Disadvantages:

• The presence of gaps in the sequence of changesets.
• Implementing this while supporting multiple SCM systems (arch, svk, etc.) would be very complex.

A private repository

Alternatively, all the versioning needs of Trac could be fulfilled by the use of a private repository. This would prevent any interference with the main repository, and lessen the complexity involved if support for other SCM systems is added.

Disadvantages:

• The need to differentiate between a WikiPage in the main repository and a WikiPage in Trac's own repository. One more level of indirection.
• It would require more administrative work to make that repository directly accessible to clients. That access would be convenient for directly editing a wiki content with a text editor.