Changes between Version 2 and Version 3 of TighterSubversionIntegration

Timestamp:

Nov 24, 2004, 3:09:02 PM (20 years ago)

Author:

cboos@…

Comment:

Explain better the current situation and needs

TighterSubversionIntegration

@@ -3 +3 @@
 == Motivation == 
 
-Trac is not a versioning system, but it allows developers to use one effectively.
+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.
+Nevertheless, Trac has its own versioning needs for its data:
+  * Wiki content versioning (for Wiki pages, ticket descriptions,...
+    actually the TracObjectModelProposal shows that there 
+    would be a wiki content for any Trac object)
+  * Versioning attachments.
 
-If one takes for granted the underlying versioning system,
-why not use it for that task instead of having to implement
+Currently, it is done that 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 VersioningSystemBackend),
+why not use this one for that task instead of having to implement
 an ad-hoc versioning scheme?
 
 That would:
- * provide better diffs than what we have now
+ * 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)
@@ -21 +31 @@
  * 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,
+   * users 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
+   * users could do some refactorings on the Wiki contenT: renamings, 
+     fixing some pervasive typographical error, etc. (see #566)
+   * users could directly add attachments to Trac objects
 
 Another feature that would be possible is to redirect a Wiki page
@@ -36 +46 @@
 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).
+in the repository. 
+Actually, that's similar to the TicketAliases idea (See #976).
 
 The same for attachments: any file from the repository could be