Changes between Version 11 and Version 12 of TighterSubversionIntegration
- Timestamp:
- Apr 8, 2016, 9:30:27 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TighterSubversionIntegration
v11 v12 1 = Advocating a Tighter Subversion Integration = 1 [[PageOutline(2-5,Contents)]] 2 2 3 = = Motivation ==3 = Advocating a Tighter Subversion Integration 4 4 5 Trac is not a versioning system, but it allows developers to use 6 one effectively. 5 == Motivation 6 7 Trac is not a versioning system, but it allows developers to use one effectively. 7 8 8 9 Nevertheless, Trac has its own versioning needs for its data: 9 * Wiki content versioning (for Wiki pages, ticket descriptions,... 10 actually the TracObjectModelProposal shows that there 11 would be a wiki content for any Trac object) 10 * Wiki content versioning: for Wiki pages and ticket descriptions, actually the TracObjectModelProposal shows that there 11 would be a wiki content for any Trac object 12 12 * Versioning attachments. 13 13 14 14 Currently, it is done this way: 15 * Each edit of a wiki page corresponds to a new database 16 record with the full content of the page 17 * Attachments are put on the file system, and repeated upload 18 leads to a new copy with a version number appended 15 * Each edit of a wiki page corresponds to a new database record with the full content of the page 16 * Attachments are put on the file system, and repeated upload leads to a new copy with a version number appended 19 17 20 If one takes for granted the presence of an 21 underlying versioning system (currently Subversion, but 22 there's discussion about other systems in VersioningSystemBackend), 23 why not use this one for that task instead of having to implement 24 an ad-hoc versioning scheme? 18 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? 25 19 26 20 That would: 27 21 * provide better (smaller) diffs than what we have now 28 * need a smaller memory footprint (each version of each wiki page 29 would not have to be stored in its full extent, only the diffs) 22 * need a smaller memory footprint (each version of each wiki page would not have to be stored in its full extent, only the diffs) 30 23 * provide versioning for attachments 31 * enable the users to directly interact with the Trac content, 32 instead of having only the Trac web interface: 33 * users could edit the wiki content with a text editor, 34 as they would do with a normal repository file 35 * users could do some refactorings on the Wiki content: renamings, 36 fixing some pervasive typographical error, etc. (see #566) 24 * enable the users to directly interact with the Trac content, instead of having only the Trac web interface: 25 * users could edit the wiki content with a text editor, as they would do with a normal repository file 26 * users could do some refactorings on the Wiki content: renamings, fixing some pervasive typographical error, etc. (#566) 37 27 * users could directly add attachments to Trac objects 38 28 39 Another feature that would be possible is to redirect a Wiki page 40 as being some actual file in the normal repository. For example, a 41 wiki page containing the description of a given software component 42 could actually be placed in the {{{doc}}} subfolder of that 43 component. Keeping it closer to the source increases its chances 44 of staying up-to-date. 29 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. 45 30 46 This Wiki redirection would be quite simple to implement: 47 the content would be a [wiki:TracLinks Trac link] pointing to a specific file 48 in the repository. 49 Actually, that's similar to the TicketAliases idea (See #976). 31 This Wiki redirection would be quite simple to implement: the content would be a [wiki:TracLinks Trac link] pointing to a specific file in the repository. 32 Actually, that's similar to the TicketAliases idea (#976). 50 33 51 The same for attachments: any file from the repository could be 52 said to be "attached" to a Trac object, instead of having to be 53 uploaded in all cases. In the end, an attachment and a file would 54 really be the same thing. 34 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. 55 35 56 57 == Implementation == 36 == Implementation 58 37 59 38 There would be essentially 2 ways to implement that integration: … … 61 40 * using a private repository 62 41 63 === A private area ===42 === A private area 64 43 65 44 A top-level folder in the repository would be used by Trac. 66 45 This could be {{{/trac}}}, but that would be configurable. 67 46 68 There would be no point in dealing with a Changeset saying 69 ''!WikiPage !AbCdEf modified'', beside the regular !WikiPage edited event, 70 except, of course, if that modification was done outside of Trac, 71 by a direct modification and commit on the Trac files. 47 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. 72 48 73 Deciding whether a changeset must be taken into account or ignored 74 could be done very simply: each revision created by Trac could be 75 remembered as such, in a {{{trac_revision}}} database table or using 76 a SVN [http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.2 revision property]. 49 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 [http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.2 revision property]. 77 50 78 51 Disadvantages: … … 80 53 * Implementing this while supporting multiple SCM systems (arch, svk, etc.) would be very complex. 81 54 55 === A private repository 82 56 83 === A private repository === 84 85 Alternatively, all the versioning needs of Trac could be fulfilled 86 by the use of a private repository. This would prevent any 87 interference with the main repository, and lessen the complexity involved 88 if support for other SCM systems is added. 57 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. 89 58 90 59 Disadvantages: 91 * The need to differentiate between a !WikiPage in the main 92 repository and a !WikiPage in Trac's own repository. 60 * The need to differentiate between a !WikiPage in the main repository and a !WikiPage in Trac's own repository. 93 61 One more level of indirection. 94 * It would require more administrative work to make that repository 95 directly accessible to clients. That access would be convenient 96 for directly editing wiki content with a text editor. 62 * 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. 97 63 98 == See also ==64 == See also 99 65 100 There had been a discussion about the pros and cons of integrating Trac with SVN more tightly. The discussion is summarized on the page [wiki:WhySQLite WhySQLite].66 There had been a discussion about the pros and cons of integrating Trac with SVN more tightly. The discussion is summarized on the page [wiki:WhySQLite]. 101 67 102 Google's googlecode implementation goes at least partially down this route, 103 using the [#Aprivatearea private area] approach. The repository root contains 104 the usual trunk, branches, and tags, plus wiki, which has all the wiki pages. 68 Google's googlecode implementation goes at least partially down this route, using the [#Aprivatearea private area] approach. The repository root contains the usual trunk, branches, and tags, plus wiki, which has all the wiki pages. 105 69 Tickets/issues and other project metadata are not stored in SVN, however. 106 70 For an example, see [http://code.google.com/p/adns-python/ adns-python]. 107 71 108 BitBucket, on the other hand, uses the [#Aprivaterepository private repository] 109 approach, which is more natural for Mercurial. 72 BitBucket, on the other hand, uses the [#Aprivaterepository private repository] approach, which is more natural for Mercurial. 110 73 111 74 [http://www.ditrack.org/ 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. 112 75 76 === Example Implementation 113 77 114 === Example Implementation === 115 of using svn for storing WikiPages is in this attachment:svn-wiki-backend-patch. See ticket:1132 for further details. 78 An example of using svn for storing wiki pages is in this attachment:svn-wiki-backend-patch. See ticket:1132 for further details.
