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:

• Wiki content versioning: for Wiki pages and ticket descriptions, actually the TracObjectModelProposal shows that there would be a wiki content for any Trac object
• Versioning attachments.

Currently, it is done this way:

• Each edit of a wiki page corresponds to a new database record with the full content of the page
• Attachments are put on the file system, and repeated upload leads to a new copy with a version number appended

If one takes for granted the presence of an underlying versioning system (currently Subversion, but there's discussion about other systems in VersionControlSystem), why not use this one for that task instead of having to implement an ad-hoc versioning scheme?

That would:

• provide better (smaller) 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:
  • users could edit the wiki content with a text editor, as they would do with a normal repository file
  • users could do some refactorings on the Wiki content: renamings, fixing some pervasive typographical error, etc. (#566)
  • users could directly add attachments to Trac objects

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 of staying up-to-date.

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

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 in dealing 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 database table or using a SVN ​revision property.

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 wiki content with a text editor.

See also

There had been a discussion about the pros and cons of integrating Trac with SVN more tightly. The discussion is summarized on the page WhySQLite.

Google's googlecode implementation goes at least partially down this route, using the private area approach. The repository root contains the usual trunk, branches, and tags, plus wiki, which has all the wiki pages. Tickets/issues and other project metadata are not stored in SVN, however. For an example, see ​adns-python.

BitBucket, on the other hand, uses the private repository approach, which is more natural for Mercurial.

​DITrack is a free, open source, lightweight, distributed issue tracking system implemented in Python that does store tickets/issues and other project metadata directly in SVN.

Example Implementation

An example of using svn for storing wiki pages is in this attachment:svn-wiki-backend-patch​. See ticket:1132 for further details.