Changes between Version 4 and Version 5 of TighterSubversionIntegration

Timestamp:

Jan 31, 2005, 1:32:52 AM (19 years ago)

Author:

ryandesign

Comment:

corrected typos

TighterSubversionIntegration

@@ -12 +12 @@
   * Versioning attachments.
 
-Currently, it is done that way:
+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
@@ -42 +42 @@
 could actually be placed in the {{{doc}}} subfolder of that
 component. Keeping it closer to the source increases its chances
-to stay uptodate.
+of staying up-to-date.
 
 This Wiki redirection would be quite simple to implement:
-the content would be a TracLinks pointing to a specific file
+the content would be a [wiki:TracLinks Trac link] pointing to a specific file
 in the repository. 
 Actually, that's similar to the TicketAliases idea (See #976).
@@ -51 +51 @@
 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
+uploaded in all cases. In the end, an attachment and a file would
 really be the same thing. 
 
@@ -58 +58 @@
 
 There would be essentially 2 ways to implement that integration:
- * using a private area in the Subversion repository being trac'ed
+ * 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.
+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 
+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,
@@ -93 +93 @@
  * 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.
+   for directly editing wiki content with a text editor.