info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Policies (was: RE: cvs add <directory>)


From: Paul Sander
Subject: Policies (was: RE: cvs add <directory>)
Date: Tue, 27 May 2003 09:53:44 -0700

>--- Forwarded mail from Greg Woods:

>[ On Sunday, May 25, 2003 at 19:51:07 (-0700), Paul Sander wrote: ]
>> Subject: RE: cvs add <directory>

>> I believe that developers must be permitted to check in their work
>> arbitrarily.

Hmmmm....  "Arbitrarily" was perhaps the wrong word to use here.

>THEN PLEASE GO USE SOME OTHER TOOL WHERE THIS USAGE PATTERN WORKS!!!!!

>In CVS this is even documented as a "Bad Thing", as it will be with most
>types of concurrent versioning systems which encourage developers to
>update early and update often:

>    When to commit?
>    ===============
>    
>       Your group should decide which policy to use regarding commits.
>    Several policies are possible, and as your experience with CVS grows
>    you will probably find out what works for you.
>    
>       If you commit files too quickly you might commit files that do not
>    even compile.  If your partner updates his working sources to include
>    your buggy file, he will be unable to compile the code.  On the other
>    hand, other persons will not be able to benefit from the improvements
>    you make to the code if you commit very seldom, and conflicts will
>    probably be more common.
>    
>       It is common to only commit files after making sure that they can be
>    compiled.  Some sites require that the files pass a test suite.
>    Policies like this can be enforced using the commitinfo file (*note
>    commitinfo::.), but you should think twice before you enforce such a
>    convention.  By making the development environment too controlled it
>    might become too regimented and thus counter-productive to the real
>    goal, which is to get software written. 

My policy is to allow developers to commit their work at any time they
deem appropriate.  There are many possible related policies that can
accomodate this.  These are a few that I have used on various projects
(usually in combination), all with success:

- Ownership of subsystems is assigned such that the concurrent paradigm
  isn't used; inter-subsystem references are resolved via baselines, and
  each user manages their own subsystems as they see fit.
- Users commit arbitrarily but must coordinate updates and integrations.
- Users commit only after acceptance criteria are met and may update at
  any time.
- The change control system (tags, branch/timestamp pairs, submit/assemble
  tools, whatever) sorts out what others see.  Changes given to the change
  control system meet acceptance criteria, other commits are arbitrary.
- Use personal branches for normal development and are managed as needed;
  merge and commit to shared branches when acceptance criteria are met.

Consider it a treat when someone actually wants to commit something.
Coach them how to do it, create a branch, even create a special place for
them if necessary.  But NEVER, EVER turn somebody away when they want to
save their work.

>Note also that more and more people are choosing to use two-phase commit
>systems such as Aegis, and those definitely do not allow arbitrary
>checkins -- they take testing and peer review to a new level!

Good for them.

>--- End of forwarded message from address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]