| Title | TeamTrack documentation unclear about line endings |
| Status | closed |
| Priority | essential |
| Assigned user | Gareth Rees |
| Product | project |
| Organization | TeamShare |
| Description | It is not clear from the TeamShare API documentation or the TeamTrack schema documentation how newlines are represented in strings read from or written to the API. |
| Analysis | When there are newlines in fields in case descriptions, these newlines are encoded as "\015\012" when the description is read from the database. But the documentation doesn't mention any such line ending convention, and the sample programs distributed with the TeamShare API don't do any newline translation on input or output. Is this an oversight? (It is critical that this is understood, otherwise the replicator will introduce inconsistencies in line endings between TeamTrack and Perforce and fail to meet requirement 1.) TeamShare stated in e-mail on 2000-09-21 that newlines are represented by carriage-return/linefeed pairs in the database and that the TeamShare API does no newline translation. This closes the issue. |
| How found | inspection |
| Evidence | <http://info.ravenbrook.com/mail/2000/09/21/14-33-20/0.txt>.< http://info.ravenbrook.com/mail/2000/09/20/15-47-46/0.txt>. |
| Created by | Gareth Rees |
| Created on | 2000-09-20 16:59:47 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 18:54:14 |
| History | 2000-09-20 GDR Created. 2000-09-21 GDR Closed, because TeamShare clarified the newline representation in e-mail. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 2996 | closed | 2000-10-10 15:00:52 | Gareth Rees | In dt_teamtrack.py: The dt_teamtrack module uses its own error object, so that errors in that module can be distinguished from errors in the replicator module. When new records are added to the fixes and filespecs relations in the VCACTIONS table, the TIME1 and TIME2 fields are set to 0, since there's no way to get valid times on the TeamTrack server machine; see my e-mail 2000-10-06 13:37:17. The classes to use for representing cases, fixes and filespecs are included in the dt_teamtrack configuration, so that they can be subclassed. New teamtrack_case methods 'transform_dt_to_p4' and 'transform_p4_to_dt' transform fields between issues and jobs, with different types of fields being transformed in different ways (users are looked up in the USERS table, etc). This allows the set of fields that are replicated to be listed in a configuration table. The teamtrack_case method 'transform_from_job' picks a transition to apply. This uses the new dt_teamtrack method 'transition'. It looks in the TRANSITIONS table to find a transition that goes from the old state to the new state. If none applies, use update() instead of transition(). Configuration for dt_teamtrack now includes 'replicated_fields', the list of fields to be replicated; 'state_dt_to_p4', a map from TeamTrack state name to Perforce status name; 'state_p4_to_dt', a map from Perforce status name to TeamTrack state name. To support replication of states and transition of issues, new dt_teamtrack method init_workflows computes a number of useful maps from the STATES, TRANSITIONS, PROJECTS and WORKFLOWS tables. New dt_teamtrack methods 'transform_state_p4_to_dt' and 'transform_state_dt_to_p4' transform TeamTrack issue states to Perforce job statuses. In replicator.py: Methods consistently take defect tracker data first and Perforce data second. New methods 'replicate_many' replicates lists of issues and jobs. This allows testers to get the replicator to replicate things without fiddling with the databases. |