Ravenbrook / Projects / Perforce Defect Tracking Integration / Project Documents
Perforce Defect Tracking Integration Project
This document summarizes design decisions for the Perforce/TeamTrack integration. The decisions were made by Richard Brooksby and Gareth Rees of Ravenbrook Limited and Kelly Shaw, John McGinley and Doug Lemaire of TeamShare at a series of meetings on 2000-08-14/2000-08-16 [RB 2000-08-04], [RB 2000-08-16], [GDR 2000-08-16], [GDR 2000-08-18a], and [GDR 2000-08-18b].
The purpose of this document is to record the decisions so that they can be confirmed by all participants in the integration and can form the basis for the maintained design of the integration.
The intended readership is integration project staff at Ravenbrook and TeamShare.
This document is not confidential.
Note that this document is a record of decisions taken in the meetings, not a design document. See [RB 2000-08-10] for the product design.
The meeting agenda is taken from [RB 2000-08-04] and quoted below.
1. MANAGEMENT
1.1. Business goals for the Perforce/TeamTrack integration.
1.2. Description of organizations and relationships, existing projects and resources.
1.3. Actual level of resource commitment from TeamShare and Perforce.
1.4. Key contacts and responsibility.
1.5. Project planning.
1.6. What's beyond this integration.
2. REQUIREMENTS AND ARCHITECTURES
2.1. Ravenbrook present an architectural overview of Perforce to TeamShare
2.2. TeamShare presents an architectural overview of TeamTrack to Ravenbrook
2.3. Ravenbrook presents an overview of major requirements on the P4DTI project
2.4. Ravenbrook presents the architecture of the P4DTI project
3. MAJOR ISSUES
(The requirements and architecture meeting will no doubt identify other issues.)
3.1. New relations and interfaces
Relating TeamTrack cases to Perforce changelists.
Relating TeamTrack cases to Perforce files.
3.2. Connecting the web interface to Perforce (Tracker-client architecture issues)
Using a plug-in
Using a helper application
Using p4web
3.3. Replicator access to TeamTrack (Replication architecture issues)
Pretending to be different users.
Synchronization of user lists.
Licensing issues: expiry, number of users exceeded.
Can the replicator be triggered by TeamTrack?
How do we represent the replication status?
3.4. The fate of TeamShare SourceBridge.
Would we continue to support the TS_VCActions table as described on page 41 of the Administrator Manual for TeamTrack 4.0?
Would we continue to support the SourceBridge access privilege as described on page 231 of the Administrator Manual for TeamTrack 4.0?
Interaction between SourceBridge and Perforce's own MSSCC plug-in.
4. DESIGN DETAILS
4.1. Handling inconsistencies
4.2. Preventing or limiting or reporting on change that is not associated with a case.
4.3. What colour should it be?
5. MISCELLANEOUS
5.1. TeamShare development licenses for Ravenbrook.
This record of the decisions made follows sections 3 and 4 of the agenda.
The replicator will replicate the cases relation in TeamTrack (stored
in the TS_CASES table) to and from the jobs relation in
Perforce. The conversion between cases and jobs will be configurable
(initially by writing a conversion function in Python; in later releases
there may be some more convenient configuration tool for organizations
where a field mapping will suffice).
Not all cases will be replicated to a Perforce server and not all jobs will be replicated to TeamTrack.
Changes to jobs in Perforce will result in transitions in TeamTrack. Specifically, creating a new job in Perforce will cause a submit transition in TeamTrack. Editing informational fields of a job (like description) will cause an update transition. Other changes (change in status, change of ownership) will cause appropriate transitions. The determination of the appropriate transition will be configurable by the administrator of the integration (since the appropriate transition in each case depends on the organization's workflow).
When a new job in the P4 interface and replicated to TeamTrack, a project must be specified. (In TeamTrack, every case belongs to a project.) The project may be specified at the Perforce end (by having a project field in the job). Where this is not done, a default must be chosen.
The associated filespec relation is needed to meet requirements 40 and 54.
There will be a relation between issues and filespecs. This relation will be many-to-many. In TeamTrack this will be represented as a relation between cases and filespecs. Perforce currently has no direct support for such a relation at present. In the integration the relation will be representing by added a text field to the jobs relation that contains a list of filespecs, one per line, like this:
Associated_Filespecs:
//depot/frobnitz/main/src/server/foo.c
//depot/frobnitz/main/src/server/...
//depot/frobnitz/main/*/server/*.c
In TeamTrack 4 this relation will be stored in the
TS_VCACTIONS table. (TeamTrack 4 does not support adding
tables to the schema.) The TS_TYPE field will contain an
integer identifying the record as an association between a case and a
filespec (not yet decided). The TS_RECID field will
contain the id of the case. The TS_FILENAME field will
contain the filespec. The TS_CHAR1 field will contain the
replicator id corresponding to the Perforce server for that record.
Note that this imposes a limit of 255 characters on the length of
replicator ids.
It may be possible in later versions of TeamTrack for the associated filespecs relation to be stored in its own table in the TeamTrack database.
TeamTrack will present this relation in the "Version Control" section of a case description, listing the filespecs associated with the case being viewed. When a case is being updated and the user has permission to do so, the use will be able to add, edit and remove filespecs for that case. See section 3.2.3 for more decisions about the TeamTrack interface to the associated filespec relation.
TeamTrack will log changes to the associated filespec relation in the
TS_CHANGES table. This will allow the replicator to work
out what changes need to be replicated to Perforce.
The replicator will replicate the associated filespecs relation to and from the equivalent relation in Perforce.
Note that although the associated filespec relation does not involve modifying the TeamTrack database schema, TeamShare must make a new release (4.0.4?) to support the interface to the relation.
We won't add queries about which cases affect a set of files in the TeamShare interface at this stage (thus not supporting use cases 6.11, 6.13 and 6.14 [GDR 2000-05-03]). The queries will be able to be be made using Perforce, or by querying the database directly.
The associated changelists relation is needed to meet requirements 44, 45, 46, 47, 48, and 49.
There will be a relation between issues and changelists. This
relation will be many-to-many. In TeamTrack this will be represented as
a relation between cases and changelists. In Perforce this will be
represented by the fixes relation. The fixes relation will be extended
so that it supports a third field, which may one of a user-configurable
set of keywords. This field will describe how the changelist affects
the job. Note that there may only be one keyword for a given case and
changelist, so that it will be illegal to have (case=4,
changelist=657, keyword=fixed) and also (case=4,
changelist=657, keyword=not-fixed).
In TeamTrack 4 this relation will be stored in the
TS_VCACTIONS table. (TeamTrack 4 does not support adding
tables to the schema.) The TS_TYPE field will contain an
integer identifying the record as an association between a case and a
changelist (value not yet decided). The TS_RECID field
will contain the id of the case. The TS_INFO1 field will
contain the id of the changelist. The TS_FILENAME field
will contain the keyword. (This is because keywords in Perforce can be
arbitrarily long.)
It may be possible in later versions of TeamTrack for the associated changelists relation to be stored in its own table in the TeamTrack database.
TeamTrack will present this relation in the "Version Control" section of a case description, listing the changelists associated with the case being viewed. See 3.2.4 for more decisions about the TeamTrack interface to the associated changelists relation.
TeamTrack will log changes to the associated changelists relation in
the TS_CHANGES table. This will allow the replicator to
work out what changes need to be replicated to Perforce.
The replicator will replicate the associated changelists relation to and from the fixes relations in Perforce.
Note that although the associated filespec changelists does not involve modifying the TeamTrack database schema, TeamShare must make a new release (4.0.4?) to support the interface to the relation.
Changelist descriptions will be replicated from Perforce to TeamTrack so that they can be displayed in the TeamTrack interface.
In TeamTrack 4 changelist descriptions will be stored in the
TS_VCACTIONS table. (TeamTrack 4 does not support adding
tables to the schema.) The TS_TYPE field will contain an
integer identifying the record as a changelist description (value not
yet decided). The TS_INFO1 field will contain the id of
the changelist. The TS_FILENAME field will contain the
description.
We won't add a special interface to ask about pending work on cases. (Pending changelists are not always handled consistently in Perforce at the moment so this may not be reliable even if we tried it.) We may add such an interface in a later release of TeamTrack.
TeamTrack can filter a list of cases by release to provide use cases 6.12 and 6.15 [GDR 2000-05-03] (since the release id is usually a field in a case). We can replicate the release field into Perforce (given appropriate configuration by the administrator) to provide a similar jobs query in Perforce. This will appear in the System Administrator's Guide.
We considered the following possibilities for changelist keywords:
The keyword is simply the state that the job will be taken to when the changelist is submitted. So it would be "closed" if the job is being closed by the changelist. However, in Perforce the workflow is a multigraph (there may be more than one transition from state A to state B). So this wouldn't be enough.
Define a fixed set of keywords with mappings into the TeamTrack workflow. This is what TeamShare have done for their Microsoft Project integration. Ravenbrook will study this integration (John McGinley is the contact). Note that workflows are hierarchical in TeamTrack: they can be local to projects. This means that the mapping may have to be more complicated than just keyword -> transition; it may need to be (keyword, project) -> transition. Note also that two entirely different transitions or states may have the same name (TeamTrack identifies them by id).
The administrator of the integration will define a set of keywords and map that specifies how they translate to workflow transitions in TeamTrack. This may be an extension to possibility 2 above (that is, we will supply a default configuration for this mapping that works well with TeamTrack's default configuration).
Note that a mapping between keywords and transitions must work in both directions, because files may be checked in during a TeamTrack transition (see section 3.2.7) and in that case we need to work out from the TeamTrack transition which keyword to put in the case/changelist relation.
We haven't made a decision about how to configure the changelist keywords.
TeamShare has no client, so how do we do operations on the client machine? There are four solutions:
Helper application. We think this is inelegant because it involves downloading a file for every action and feeding it to the helper application. This will be slow and won't work on many platforms. (This is how RealAudio works, but it doesn't work very well.)
Connect to p4web. This is a web server that runs on the client machine. It talks Perforce protocol to the Perforce server and provides a user interface through a browser on the client machine. This is portable to lots of browsers and operating systems, and it's cheap. However, not many people like p4web because it's inconvenient for every user to administer a server on their local machine.
Browser plug-in. The plug-in will include the Perforce API so it
can talk to the local disk and talk to the Perforce server. You will
use <EMBED ...> tags to provide an HTML interface to
Perforce. This limits the browsers and operating systems we can support
to Netscape and Internet Explorer on Windows and (some) Unix, but it's
much the nicest solution. A generic plug-in could be used to add
tracker-client implementations to lots of other defect tracking systems
(Bugzilla, for example).
Java applet. We'd have to tell customers to turn off all the security in their browser so that the applet could write to local disk. Also, it's very hard to write Java applets that work on a variety of systems. Java just isn't reliable enough.
Our preferred solution is the browser plug-in, but this depends on Perforce being prepared to fund development of such a plug-in. If that doesn't happen in time, then our back-up solution is to connect to p4web.
TeamTrack will support the following source control operations:
Associate file.
Disassociated file.
View latest revision (p4 print).
View file history (p4 filelog).
View differences in the repository (p4 diff2).
Check out file for edit (p4 edit).
Undo check out (p4 revert).
Check in (p4 submit).
Get latest version (p4 sync).
View differences (p4 diff).
TeamTrack won't support advanced operations like branching and merging. Users will have to use the Perforce interface for these.
Associating and disassociating files to and from a case will be possible through the "update case" form (see 3.2.3).
Source control operations that can be done without changing the Perforce repository or the local disk (namely, print, filelog and diff2) will be available from the "view case" form in TeamTrack for files associated with that case.
Other source control operations will only be available during a transition of a case (for files associated with that case). John thinks it important that any change (to the repository or to local disk) be associated with a transition. This approach makes all changes traceable, and integrates well with TeamTrack's prvileges mechanism.
The operations "check out for edit" and "get latest version" will be available in the "update" transition, and possibily other transitions, depending on an organization's workflow definition.
Figure 1 below shows a rough outline of where these source control operations will be available through the TeamTrack interface. The proposal needs a lot of work: for example, when there are many files associated with a case, it may be too tedious to select "check out" on all the drop-downs.
Figure 1. Proposal
for TeamTrack's update interface
Note that these design decisions mean that users of the TeamTrack interface must associate a file with a case before they can do source control operations on it. This is good, because actions are traceable. Also, it is similar to the situation in Visual Studio where you have to associate files with a project before you can do source control operations on them.
We considered clearly separating the source control operations from the defect tracker. In this scenario the TeamTrack interface would show only a "Source Control" button; when you pressed it you would get a separate source control application). This would avoid implying that TeamTrack were trying to be a source control system as well as a defect tracking system. But the user requirement is to make things as easy as possible. So we decided to rule out this scenario.
We considered whether the buttons in the TeamTrack interface should have generic names, like "check in" and "check out", or Perforce-specific ones like "submit" and "edit", or both. Generic names are better for users familiar with SCM concepts from tools like CVS, Visual Source Safe and Developer Studio. Perforce-specific names would make the integration easier to support, and be better for users familiar with Perforce. No decision was made.
In the "view case" form, TeamTrack will display a the filespecs associated with the case, one per line. See figure 1.
In the "update case" form, there will be an edit button which pops up a window in which the filespecs appear in an edit box, one per line. (Doug said that this is better than having the edit box appear directly in the "update case" form because it allows for validation and is also good for future integrations with other software, because it doesn't modify the main form design.) See figure 1.
Note than in p4win, the "copy" operation on a selected file copies a filespec into the cut buffer. It can then be pasted into the TeamTrack edit field.
We will provide a function allowing TeamTrack to do syntax validation of filespecs.
When selecting filespecs in order to apply a source control operation, check boxes are better than a multiple selection list. This is because it is easy to lose work in a multiple selection list, hard to lose work in a list of check boxes.
In a mature Perforce system, there are tens or hundreds of thousands of changelists. It won't be practical to put their descriptions in a drop box.
Instead, we'll have an edit field and a drop box. The drop box is initially empty (or perhaps it has some number of recent changelists in it). If you know the number of the changelist you want, you can type it in. Otherwise you can type a search term. This gets sent to the Perforce server which returns the matching changelist descriptions, which get put in the drop box.
TeamTrack will add new kinds of permissions to the TeamTrack privileges table. This controls which source control operations are available to which users at which step in the workflow. In turn, this controls which buttons in the interface are enabled.
Of course someone can always go behind the back of the system by doing their edits in Perforce (see section 4.2).
Each Perforce client only works on one machine, but the TeamTrack interface is machine-independent. There must therefore be some way for TeamTrack users to specify clients and edit them. The interface to this needs to be understandable (clients are an advanced feature in Perforce).
For operations which don't change the repository or the local disk (print, filelog, diff2), we don't need a client at all.
But for other operations we need to select a client somehow. TeamTrack must record this somehow, perhaps in a cookie.
Files can be checked in through the TeamTrack interface only during a transition. The kind of transition indicates how the changes to the files affect the case, and therefore which keyword will appear in the case/changelist relation (see section 3.1.5).
Figure 2 below shows a rough outline of where the check in interface will look in the TeamTrack interface. The proposal needs a lot of work.
Figure 2. Proposal
for TeamTrack's check in interface
Note that when you launch a transition that gives you the option of checking in some files, you must decide to check in or revert every file (you can't leave any as "none"). You can't submit some of your work on the case and leave some of it. This merely enforces good practice. Of course, if you must check in only some of your work on the case, you can switch to the Perforce interface (recall that requirement 38 is only that routine tasks source control can be carried out through the defect tracking interface).
Note also that the associated files don't default to "check in" or to "revert" as either would be dangerous. The user must make the decision.
If checking in fails, then there will be no transition in TeamTrack (see section 3.2.8 below for an explanation of how this is achieved). The user is returned to the same transition dialog, just as if the case had failed validation in TeamTrack. The TeamTrack interface won't support Perforce resolution (remember, routine source control operations only). Users will have to go to Perforce to do the resolution.
This is the classic two-phase commit problem. The TeamTrack transition might fail (because data doesn't validate or the transition is illegal) and the Perforce submit might fail (because of the need to resolve). We don't want either change to go ahead without the other. Remember that checking in can take arbitrarily long (imagine adding a lot of files across a slow network).
TeamTrack does not support locking records in the database and will not do so for the foreseeable future. We considered two strategies:
Validate the TeamTrack transition without actually committing it (that is, determine if it would succeed). If it would, then do the submit in Perforce. If that succeed, commit the TeamTrack transition. This may result in an inconsistency if the case is changed in the TeamTrack database while the Perforce submit is being processed. We expect this to be rare enough (because case ownership in TeamTrack means that it is rare for two people to change the same case simultaneously) that this is a workable solution. TeamTrack doesn't have a call in the API for validating a transition. Can this be added?
Lock the Perforce submit without committing it. If that succeeds, commit the TeamTrack transition. If that succeeds, commit the Perforce submit. If it fails, unlock the records in Perforce. We don't yet know enough about locking in Perforce to know if this is possible.
Note that TeamTrack doesn't have anything in the way of conflict resolution. If there are two simultaneous transitions, then one of them wins.
Neither proposal is really a two-phase commit solution. In either case we may end up in a situation (after a crash, say) where one database has changed but not the other. In these cases the replicator will eventually discover the inconsistency and resolve it or report it to the administrator depending on the configuration (see section 4.3).
When a user has done a simultaneous check in and transition using the TeamTrack interface, we need to stop the replicator from replicating since in this case we've done both sides of the synchronization ourselves. This includes even the fixes relation. We do this by making sure that the replicator doesn't think the issue needs to be replicated -- perhaps by setting the "last replicated" date to the "last modified" date on each side (see section 3.3.3).
TeamTrack has the capability to create "superusers": that is, users with privileges that allow them to submit or transition cases owned by anyone (or perhaps by anyone in a given project). We will require the administrator to create such a user (or specify such a user if one already exists) when the integration is installed, and configure the replicator to connect as that user.
We will require the administrator to specify a mapping between users in TeamTrack and users in Perforce for each Perforce server. This is really a set of triples of the form (TeamTrack user, Perforce server, Perforce user). Perforce servers may correspond to replicator ids so we may be able to use replicator ids here. The administrator must edit the mapping when a user is added to both systems.
The reason for requiring the administrator to specify this mapping is that there is no way for the integration to be able to deduce it.
When the replicator replicates a case from TeamTrack to Perforce, it
looks up the TS_USER field of the case in the mapping to
discover the corresponding Perforce user, which is entered in the
appropriate field of the Perforce job (and vice versa).
If a user is not found in the mapping, then that is an inconsistency. (See section 4.1 for design decisions relating to inconsistencies.) The reason for this is that we can't just create a user in the other system, because such a user must be licenced, it's very unlikely that there any organization will have spare licences sitting around, and it may allow people to easily get around licencing restrictions.
We thought about the possibility of having some user to default to when a case can't be replicated because there's no corresponding user. This would at least make sure that data wasn't lost. The default user could be the TeamTrack administrator, or maybe the manager of the project which the case belongs to. But this is also a bad idea since it can be exploited to get around licencing restrictions.
Note that a consequence of this is that every user of the integration must have licences on both systems, even though they may only be using one of the interfaces to the integrated systems.
Note that the replicator shouldn't make changes to the TeamTrack
database that aren't allowed by the TeamTrack permission rules. This
should be possible using the TeamShare API by calling the
TSServer::TransitionRecord method to do all changes to the
TS_CASES table. The method will fail if the proposed
transition is illegal for the user specified in the method call. (I
believe that the replicator doesn't have to log in as the user who is
making the transition.)
Yes, by using a post-transition macro in TeamTrack. TeamTrack has a macro language called TeamScript, similar to Visual Basic. This language is used by TeamShare's PSG (Professional Services Group) to customize TeamTrack. TeamScript has the capability to launch an executable, so it would be possible to make the replicator listen on a port and have a TeamScript macro run after every relevant change to the TeamTrack database, connect to the port, and indicate to the replicator what has changed.
In TeamTrack 4, TeamScript is not publically supported. In later versions it may be open and supported. TeamShare are willing to support it for this integration.
For cases, we will add a field that contains a time that the case was last known to be consistent with Perforce. (Similarly, we will add a field to the jobs relation that contains a time that the job was last known to be consistent with TeamTrack.) These times will actually be lower bounds on the time it was last known to be consistent. On the TeamTrack side there will need to be such a field for each Perforce server that we may be replicating to.
This means that we can select records needing replicating by asking for records whose modification time is more recent than the time they were last known to be consistent. When we have replicated a record, we set its "last known to be consistent" time to its modification time. (Note: we must take care to avoid race conditions here when another change is entered into the database before we have finished replicating this one.)
We must not copy time from the replicator into either database, otherwise clock skew will kill us. We must use the database's own idea of what time it is. The replicator must never compare its own time with the database's time.
Supposing a record can't be replicated because of an inconsistency. We don't want to keep picking up this record, discovering that is inconsistent, and sending e-mail. We need to store a flag in the record with the meaning "known to be inconsistent; don't try to replicate". This needs to be another field in the cases table.
For the other replicated relations (case/filespec, case/changelist) we have no proposal for representing the replication status. This needs to be considered.
In a TeamShare/Perforce integrated environment, users won't use SourceBridge; they will use Perforce's own Developer Studio integration. The system administrator's guide and user guide will include notes on this. TeamShare will continue to support SourceBridge for customers who don't use the integration with Perforce.
Perforce's IDE plug-ins will have job manipulation interfaces. Ravenbrook will liaise with Perforce and Glyphic Technology (plug-in developers) to make sure this happens.
It would be nice if the integration could detect the presence of SourceBridge and tell people to do something about it.
We identified three kinds of inconsistencies that can occur:
Two simultaneous changes to the same record.
A change made in Perforce is illegal in TeamTrack.
A record in one database cannot be converted to a record in the other database (for example, because the user who owns the case in TeamTrack has no corresponding user in Perforce).
The responses to an inconsistency should be configurable by the administrator. They should include:
Carry out the illegal action anyway.
In case of an inconsistency, TeamTrack is always right.
In case of an inconsistency, Perforce is always right.
Apply a heuristic (perhaps written as a function in Python) to resolve the inconsistency).
Don't try to automatically resolve the inconsistency.
When an inconsistency is discovered (even if it is automatically resolved by one of the rules above), a human may be notified. This may be the administrator of the integration, or it may be the manager of the project to which the erroneous case belongs. TeamTrack supports notifications that run when a rule is met: these may be useful to implement this. See the TeamTrack administrator manual.
We also considered the following possibilities, which are bad ideas:
In case of an inconsistency, the most recent change is right (this is a bad idea because of clock skew between the TeamTrack and Perforce server machines).
Creating users where they don't exist (see section 3.3.1).
Converting unknown users to some default user (see section 3.3.1).
Banning further changes until the inconsistency is resolved. (This may be feasible in TeamTrack by taking everyone's licence away! Of course you need to keep track of who had which licence so you can put them back later. The administrator's licence must be left in place.)
We need to detect the situation where two people transition the same case and make different changes to the fixes relation. We need to have a general "check for consistency" mechanism that detects all sorts of consistency problems. This should run separately from the replicator and act as an independent check on it.
If a job is reassigned, then its checked out files can never be submitted through the TeamTrack interface. Someone has to go around and revert these files to prevent them clogging up the system. We will provide a tool to identify when this has happened.
TeamTrack will extend their privileges so that they cover source control activity. This will allow managers to set up rules like "you can only check out for edit or check in files associated with a case if you are the owner of that case". However, since Perforce doesn't have such a capable privileges system, we won't be preventing change through Perforce. So users may be able to cheat by using Perforce to do changes they would not be allowed to.
See section 4.4 for decisions relating to reporting.
We must make our default integration configuration work with TeamShare's default stuff and Perforce's default configuration so that people can get started easily.
Where is the replicator's configuration stored? We really ought to store it in a table in TeamTrack. But this isn't general: it may not work with other defect tracking systems. This needs some thought.
We decided to defer some of the work on reporting capabilities (for example when QA want to check that all necessary changes have been made and no unnecessary changes), at least until TeamTrack has better reporting capabilities. We will write some material in the user guide about how to do this using the reporting capabilities of the back end database (Access, Oracle, whatever). We may provide a reporting implementation for Microsoft Access (because it is the lowest common denomindator).
We need to determine which releases of TeamTrack the integration
will support and how it will detect that the release is not supported.
(Note that TeamTrack's TS_SYSTEMINFO table has a database
version field which gives the schema version.)
We need to check that integration with Developer Studio and other IDEs support all the features we need (see section 3.4).
We need to assign values for the TS_TYPE field in
the TS_VCACTIONS table for records that represent
case/filespec relations, case/changelist and changelist description
records (see sections 3.1.2, 3.1.3 and 3.1.4).
We need to make a decision about how to configure the changelist keywords, and what those keywords mean in terms of transitions in TeamTrack (see section 3.1.5).
For the replicated case/filespec and case/changelist relations we need to decide how to represent the replication status (see section 3.3.3).
We need to decide how to select appopriate TeamTrack projects for new jobs in Perforce (see section 3.1.1).
We need to decide if source control operations have generic or Perforce-specific names (see section 3.2.2).
We need to figure out a way for TeamTrack to select, edit and record a user's Perforce client spec (see section 3.2.6).
We need to determine if Perforce can lock submits and if there's an appropriate interface (see section 3.2.8).
We need to determine if TeamShare can add a function to their API that validates a transition without committing it (see section 3.2.8).
We need to specify a mechanism by which TeamTrack can detect the presence of the integration/replicator.
We need to specify how installation is going to work. Will the integration be installed at the TeamShare installation stage, or do you install the integration separately? The replicator will not be shipped with Perforce: it will be an extra download from the Perforce web site. It will probably not be shipped with TeamTrack either: TeamTrack's documentation will say to get the components from the Perforce web site.
| [RB 2000-08-04] | "RE: Visiting TeamShare in August" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2000-08-04 18:28:23 GMT. |
| [RB 2000-08-10] | "Product Design Documents"; Richard Brooksby; Ravenbrook Limited; 2000-08-10. |
| [RB 2000-08-16] | "Notes from meeting with John McGinley and Doug Lemaire of TeamShare, 2000-08-15" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2000-08-16 17:27:54 GMT. |
| [GDR 2000-05-03] | "Requirements and Use Cases for Perforce/Defect Tracking Integration"; Gareth Rees; Ravenbrook Limited; 2000-05-03. |
| [GDR 2000-08-16] | "Meeting with GDR and John McGinley, 2000-08-14" (e-mail message); Gareth Rees; Ravenbrook Limited; 2000-08-16 14:45:43 GMT. |
| [GDR 2000-08-18a] | "Perforce/TeamTrack integration design meeting, 2000-08-15" (e-mail message); Gareth Rees; Ravenbrook Limited; 2000-08-18 16:45:26 GMT. |
| [GDR 2000-08-18b] | "TeamShare/Perforce integration planning meeting, 2000-08-16" (e-mail message); Gareth Rees; Ravenbrook Limited; 2000-08-18 16:45:26 GMT. |
| 2000-08-18 | GDR | Created based on [RB 2000-08-04], [RB 2000-08-16], [GDR 2000-08-16], [GDR 2000-08-18a], and [GDR 2000-08-18b]. |
| 2000-08-29 | GDR | Readership now project staff only. Added reference to product design [RB 2000-08-10]. |
| 2000-09-13 | GDR | Explained how the replicator ensures that TeamTrack permissions are respected (section 3.3.1). |
Copyright © 2000 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.
$Id: //info.ravenbrook.com/project/p4dti/template/default.html#5 $
Ravenbrook / Projects / Perforce Defect Tracking Integration / Project Documents