FreeTDS Development Group

[Craig Spannring <cts AT internetcds.com>]

Brian Bruns writes:
 > 
 > Well it looks like we will be getting a CVS tree sometime soon. (Thanks to
 > Craig).  

 > But we have to decide what we want the directory structure to
 > look like.  Anyone have any comments on this? The src directory structure
 > should work pretty well (sans the .lib dirs). But we need to get all the
 > administratia (README, INSTALL, TODO, etc...) put somewhere, adn probably
 > some other issues.

We also need to consider a few other things.  

1) Checkout model

  CVS allows two different models of checkouts, reserved and
  unreserved.  With reserved checkouts when a developer checks out a
  file for modification it locks that file in the repository.  No other
  developer can check it out for modification.
  
  Unreserved checkouts allow multiple developers to work on the same
  file.  When the developers check in their changes CVS tries to merge
  the multiple changes.  This model relies on the fact that most of the
  time when two developers work simultaneously on the same file 
  they are generally working on different sections of the file.  It also
  assumes that they have a good level of communication and cooperation.
  CVS can provide some help with the communication.
  
  I would lean toward the unreserved checkout model.
  
2) Committers

  We also need to decide who will have commit rights to the repository.
  Since TDS is a small project I would imagine there should only be a
  small number of people with commit rights.

3) Access method

  We could use on of three access methods for the repository-
    a) rsh (or ssh)
    b) CVS password authentication
    c) kerberos
  
  Since this decision has security ramifications for InternetCDS I
  reserve the right to ignore the group consensus.
  
  I am leaning toward the password authentication method.  This allows
  developer and anonymous access without having to give actual login
  accounts to the server.  It doesn't completely prevent developers from
  running arbitrary scripts on the server, but it does make it a little
  more work.
  
  Other problems with it is that it transmits passwords in clear text
  and (I think) password maintenance will require a little more work on
  the administrators part.

4) Starting point for the repository

  Do we want to start the repository from version 0.1.  The problem with
  doing this is that the directory structure has changed and it might be
  unwieldy to beat the 0.1 directory structure into the 0.3 style.
  
  Unless someone wants to give me three tar files with versions 0.1,
  0.2, and 0.3 I will just start with version 0.3.


5) Commit policy

  When should developers be allowed to commit code?  If checkins are too
  frequent then developers could find the current sources not working at
  all.  If the commits are too infrequent the chances of conflict are
  greater.
  
  Regardless of how frequent the checkins are we need to have a tag
  for the latest version that meets some set of quality control
  standards.



-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Ski hard, Bike fast.       | cts AT internetcds.com
 --------------------------------+------------------------------------
 Any sufficiently perverted technology is indistinguishable from Perl.
=======================================================================