Edgewall Software

Changes between Version 11 and Version 12 of TighterSubversionIntegration


Ignore:
Timestamp:
Apr 8, 2016, 9:30:27 PM (3 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • TighterSubversionIntegration

    v11 v12  
    1 = Advocating a Tighter Subversion Integration =
     1[[PageOutline(2-5,Contents)]]
    22
    3 == Motivation ==
     3= Advocating a Tighter Subversion Integration
    44
    5 Trac is not a versioning system, but it allows developers to use
    6 one effectively.
     5== Motivation
     6
     7Trac is not a versioning system, but it allows developers to use one effectively.
    78
    89Nevertheless, 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
    1212  * Versioning attachments.
    1313
    1414Currently, 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
    1917
    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?
     18If 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?
    2519
    2620That would:
    2721 * 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)
    3023 * 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)
    3727   * users could directly add attachments to Trac objects
    3828
    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.
     29Another 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.
    4530
    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).
     31This 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.
     32Actually, that's similar to the TicketAliases idea (#976).
    5033
    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.
     34The 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.
    5535
    56 
    57 == Implementation ==
     36== Implementation
    5837
    5938There would be essentially 2 ways to implement that integration:
     
    6140 * using a private repository
    6241
    63 === A private area ===
     42=== A private area
    6443
    6544A top-level folder in the repository would be used by Trac.
    6645This could be {{{/trac}}}, but that would be configurable.
    6746
    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.
     47There 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.
    7248
    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].
     49Deciding 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].
    7750
    7851Disadvantages:
     
    8053 * Implementing this while supporting multiple SCM systems (arch, svk, etc.) would be very complex.
    8154
     55=== A private repository
    8256
    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.
     57Alternatively, 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.
    8958
    9059Disadvantages:
    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.
    9361   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.
    9763
    98 == See also ==
     64== See also
    9965
    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].
     66There 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].
    10167
    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.
     68Google'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.
    10569Tickets/issues and other project metadata are not stored in SVN, however.
    10670For an example, see [http://code.google.com/p/adns-python/ adns-python].
    10771
    108 BitBucket, on the other hand, uses the [#Aprivaterepository private repository]
    109 approach, which is more natural for Mercurial.
     72BitBucket, on the other hand, uses the [#Aprivaterepository private repository] approach, which is more natural for Mercurial.
    11073
    11174[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.
    11275
     76=== Example Implementation
    11377
    114 === Example Implementation ===
    115 of using svn for storing WikiPages is in this attachment:svn-wiki-backend-patch. See ticket:1132 for further details.
     78An example of using svn for storing wiki pages is in this attachment:svn-wiki-backend-patch. See ticket:1132 for further details.