Changes between Initial Version and Version 1 of TighterSubversionIntegration

Timestamp:

Nov 21, 2004, 11:57:03 AM (20 years ago)

Author:

cboos@…

Comment:

Initial proposal

TighterSubversionIntegration

@@ +1 @@
+= 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.
+
+The only disadvantage of this approach would be the presence
+of gaps in the sequence of changesets.
+
+
+=== 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.
+
+The disadvantage of this approach are:
+ * 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.