| 33 | | while working on the #1242 patch. |
| 34 | | |
| 35 | | A basic implementation is now available in the |
| 36 | | [source:branches/cboos-dev/xref-branch xref-branch], |
| 37 | | as part of the support for cross-references, |
| 38 | | and is candidate for inclusion in the trunk. |
| 39 | | |
| 40 | | Further work will continue on the more experimental branch |
| 41 | | [source:branches/cboos-dev/trac-obj-branch trac-obj-branch], |
| 42 | | where more power will be added to the generic Trac object. |
| | 36 | while working on the TracCrossReferences feature: |
| | 37 | for implementing generalized back links, I had to have a |
| | 38 | common interface to all the Trac objects, this was a practical |
| | 39 | reason to introduce the `TracObject` |
| | 40 | (see source:sandbox/trac-xref/trac/object.py). |
| 101 | | * The unique identity is the Wiki page name. -- {{{s/page_name/id}}} |
| 102 | | * The wiki syntax is the one described in WikiPageNames. |
| 103 | | -- currently present in source:trunk/trac/WikiFormatter.py |
| 104 | | {{{r"(?P<wikihref>!?(^|(?<=[^A-Za-z]))[A-Z][a-z]+(?:[A-Z][a-z]*[a-z/])+(?:#[A-Za-z0-9]+)?(?=\Z|\s|[.,;:!?\)}\]]))"}}} |
| 105 | | and in source:trunk/trac/Search.py {{{r = "((^|(?<=[^A-Za-z]))[!]?[A-Z][a-z/]+(?:[A-Z][a-z/]+)+)"}}} |
| 106 | | * The main facet would be ''content'', i.e. the content of the Wiki page itself. |
| 107 | | * The relevant fields: |
| 108 | | * author and creation time |
| 109 | | * a ''readonly'' boolean field |
| 110 | | * Wiki attachments are there |
| 111 | | * The change history would be contributed comments only, but that would make sense. |
| 112 | | * Wiki history and revision diffs are there |
| | 110 | The Wiki Page object would gain the ability to have custom fields. |
| | 111 | |
| 116 | | * The unique identity is the revision number -- {{{s/rev/id}}} |
| 117 | | * The wiki syntax is {{{r"(?P<changesethref>!?(\[\d+\]|\br\d+\b))"}}} |
| 118 | | * The main facet is 'content', which is the original commit log entered in Subversion. |
| 119 | | See #781. |
| 120 | | * Changeset properties: |
| 121 | | * author and creation time are those of the commit information. |
| 122 | | * Custom properties could be used for many things, as a way to |
| 123 | | annotate the revision. Some ideas are: |
| 124 | | * a boolean ''compilable'' flag (true by default, could be set to |
| 125 | | false to indicate that this revision can't be built) |
| 126 | | * a field indicating the % of successful test cases |
| 127 | | * a QA status |
| 128 | | * Attachments for a changeset also make sense: |
| 129 | | * in case of a build failure, the corresponding errors from the compiler |
| | 115 | The changeset message can be considered to be a ''facet'' for that object. |
| | 116 | Editing the message would be handled very similarly to editing the wiki |
| | 117 | page content (see #781). It will be versioned, like the content for wiki |
| | 118 | pages are. |
| 131 | | could be attached. |
| 132 | | * patches that applies to that revision |
| 133 | | * A change history for a Changeset, wouldn't that be cool? |
| 134 | | Actually, the contributed comments could be used for code reviews |
| 135 | | The history and diffs for the commit log are useful once the |
| 136 | | changelog becomes modifiable |
| | 120 | If the underlying VersioningSystemBackend supports it, the change |
| | 121 | could be reflected in the repository itself (not all versioning |
| | 122 | systems support that: e.g. SVN does, Mercurial does not). |
| | 123 | A `resync` operation would simply add a new revision for the |
| | 124 | message, if something changed. |
| | 125 | |
| | 126 | Custom properties could be used for many things, as a way to annotate |
| | 127 | the revision. Some ideas are: |
| | 128 | * a boolean ''compilable'' flag (true by default, could be set to |
| | 129 | false to indicate that this revision can't be built) |
| | 130 | * a field indicating the % of successful test cases |
| | 131 | * a QA status |
| | 132 | |
| | 133 | Attachments for a changeset also make sense: |
| | 134 | * in case of a build failure, the corresponding errors from the compiler |
| | 135 | could be attached. |
| | 136 | * patches that applies to that revision |
| | 137 | |
| | 138 | The contributed comments could be used for code reviews |
| | 139 | |
| | 140 | It would also be nice to be able to query changesets (see #2465). |
| | 141 | |
| 140 | | * The unique identity for a ticket is its number -- {{{id}}} |
| 141 | | * The wiki shortcut syntax is {{{r"(?P<tickethref>!?#\d+)"}}} |
| 142 | | * The main facet is ''description'' |
| 143 | | * The ticket fields: |
| 144 | | * author and creation time |
| 145 | | * milestone and component |
| 146 | | * The short summary |
| 147 | | * The keywords |
| 148 | | * An optional due time |
| 149 | | * Assigned to... |
| 150 | | * Cc field |
| 151 | | * Custom properties as usual |
| 152 | | * Attachments for tickets are there |
| 153 | | * The change history is there |
| 154 | | * The wiki history and diff would be usefull if the description is to be modified |
| | 145 | There's currently no way to have an history of the description facet. |
| | 146 | Otherwise, the Ticket has pretty much all of the generic functionality. |
| | 147 | |
| | 148 | There's also the question of having greater flexibility for ticket fields: |
| | 149 | * different sets of fields for different types of tickets (see #2464) |
| | 150 | * less difference between custom ticket fields and ''normal'' ticket fields |
| | 151 | (some kind of unification would be great here) |
| | 152 | * possibility to have multiple values for a field (see #221, #918 and #1730) |
| | 153 | |
| | 154 | There's also the question of bringing together Milestone |
| | 155 | and Ticket objects for implementing SubTickets. |
| 159 | | * The identifier for a file or directory is its path |
| 160 | | * There's no facet attached to a source |
| 161 | | * Fields |
| 162 | | * author, creation date |
| 163 | | * The size |
| 164 | | * The mime-type |
| 165 | | * dynamical svn properties |
| 166 | | * attachments for files... Why not? One could already do it with |
| 167 | | Subversion anyway ({{{svn pset prop -F attachment source}}}) |
| 168 | | |
| 169 | | |
| 170 | | == Implementing Trac Objects == |
| 171 | | |
| 172 | | For processing Trac objects and for the logic associated to them, |
| 173 | | there would be a corresponding {{{Module}}} subclass |
| 174 | | (see TracPluggableModules). |
| 175 | | That is, some modules would use some kind of Trac objects: |
| 176 | | * The !WikiModule is using the !WikiPage object. |
| 177 | | * The !TicketModule and the !NewticketModule are using the Ticket object |
| 178 | | * The Browser and Log modules will be using the Source object |
| 179 | | * etc. |
| 180 | | |
| 181 | | For the object-relational mapping, I would suggest having |
| 182 | | a table for each class, with common column names where appropriate |
| 183 | | (at the very least, the {{{id}}} column). |
| | 160 | Currently, there's no facet attached to a source. |
| | 161 | One could imagine having a summary or description facet. |
| | 162 | This could give a repository browsing experience close |
| | 163 | to what Sun did for |
| | 164 | [http://cvs.opensolaris.org/source/xref/on/usr/src/ OpenSolaris]. |
