Skip to Content.
Sympa Menu

freetds - Re: CVS structure

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Craig Spannring <cts AT internetcds.com>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Cc: mrcpu AT internetcds.com
  • Subject: Re: CVS structure
  • Date: Thu, 10 Sep 1998 13:01:44 -0700 (PDT)


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.
=======================================================================



  • CVS structure, Brian Bruns, 09/06/1998
    • <Possible follow-up(s)>
    • Re: CVS structure, Craig Spannring, 09/10/1998

Archive powered by MHonArc 2.6.24.

Top of Page