Mime-Version: 1.0
Message-Id: <p05001907b63f135bb729@[193.112.141.254]>
In-Reply-To: <p0433011fb63f0885c91e@[193.112.141.252]>
References: <p05001904b63ee8218f3b@[193.112.141.254]>
 <p0433011fb63f0885c91e@[193.112.141.252]>
Date: Mon, 20 Nov 2000 17:51:10 +0000
To: Richard Brooksby <rb@ravenbrook.com>
From: Gareth Rees <gdr@ravenbrook.com>
Subject: Re: Automatic configuration design
Cc: p4dti-staff@ravenbrook.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 17:13 +0000 2000-11-20, Richard Brooksby wrote:
>At 2000-11-20 15:35 +0000, Gareth Rees wrote:
>
>>	TITLE 	105 Title line 80 required	Line
>
>What happens if  the TeamTrack TITLE field has more than 80 characters?

The TITLE field has length 80.  But I suppose the replicator should 
look at its actual length, just in case.

>>    1. The Perforce field number is the next in sequence, starting at 106.
>
>I suggest starting at a higher number, just in case Perforce add 
>some more "system" fields.

OK, how about starting at 110?

>>Entries with ? are field types that I'm not sure how to map (except 
>>for SUMMATION they are all multiple selection fields).  It would be 
>>straightforward to map the data using some scheme like making the 
>>corresponding field a text field in Perforce and putting one entry 
>>per line, but Perforce doesn't provide a multiple-selection 
>>interface.  Some thought required here (we could replicate by 
>>listing *all* the selection options one per line in a text field 
>>and ticking the selected ones?)
>
>I suggest that we don't support multiple selection fields, at least 
>for the beta, and possibly never.  If we get requests to support 
>them, then I suggest a comma-separated list, though we won't be able 
>to validate it in the Perforce interface.

The trouble with a comma-separated list is that it gives little clue 
as to what the options are.  Something like

   [ ] option 1
   [X] option 2
   [X] option 3

would be better if people are going to be expected to edit the list.

But I agree, let's not support these fields in the beta.  People who 
desperately need them can write their own translators.

>What happens when the configuration is changed to add new fields?  I 
>suggest making the order of fields in the configuration significant, 
>so that the field IDs in Perforce are derived from their positions. 
>We can then warn people only to append fields if they don't want to 
>lose their data.  I'm worried about the long term effects of this, 
>though, as it doesn't give a way of removing fields.

If we wanted to be more robust, we could read the existing jobspec 
and avoid renumbering existing fields.

>The configuration function should generate the full configuration 
>and the jobspec, and set the Perforce jobspec every time it runs. 
>We'll need to put a strong warning in for people who already have 
>jobs in their systems.  The field comments in the jobspec should be 
>generated from the field help in the TeamTrack database.
>
>What happens when the type of a field changes?

I think that Perforce can cope; it re-interprets the data in the 
field according to the new type.  However, some changes of type may 
make some fields invalid, in which case organizations who change the 
types of fields may have to go through all their jobs and make them 
valid again.