Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Source code control policy

I'm looking for an overview over different source code control policies. I only came across the Main-Line policy and would like to better know others before committing to one with the team.

Can someone provide a link to an overview or even give me some names of policies so I can launch google on it?

like image 523
boutta Avatar asked Sep 23 '08 06:09

boutta


People also ask

What is source control policy?

Source control (or version control) is the practice of tracking and managing changes to code. Source control management (SCM) systems provide a running history of code development and help to resolve conflicts when merging contributions from multiple sources.

What is an example of source control?

Source control refers to the use of masks to cover a person's mouth and nose and to help reduce the spread of large respiratory droplets to others when the person talks, sneezes, or coughs.

How source code control system works?

Source Code Control System (SCCS) is a version control system designed to track changes in source code and other text files during the development of a piece of software. This allows the user to retrieve any of the previous versions of the original source code and the changes which are stored.


4 Answers

No empty commit messages.

like image 134
Vilmantas Baranauskas Avatar answered Oct 01 '22 02:10

Vilmantas Baranauskas


The paper "streamed lines: branching patterns for parallel software development" is an excellent discussion on branching patterns such as the "main line" pattern you mention - it lists the options in the form of patterns together with discussion of anti-patterns. One of the authors is Robert Orenstein of Perforce.

like image 36
Richard Avatar answered Oct 01 '22 01:10

Richard


We use several practical rules as commit policy in our project. These rules help us to keep every revision in ready-to-deployment state. Our rules are similar to KDE commit policy, posted here: http://techbase.kde.org/Policies/SVN_Commit_Policy. Every commit should be (from higher to lower priority):

  • Successfully checked (compiled, tested, reviewed, FxCop'ed, etc.)
  • Atomic (should contain only one logical change, f.e. single bugfix, refactoring, etc.)
  • Non-redundant (no unused code should be added, do not commit commented code, delete it, do not commit accidentally format changes, etc)
  • Correctly and fully commented
  • Matched current development phase (for example no refactoring should be allowed in version support branches)
  • As small as possible to match previous rules.

We developed a simple tool SvnCommitChecker, witch helps us to check some of these rules before commit to svn. I plan to put it to sourceforge in near future with an article about benefits of keeping good svn change history.

like image 43
Eugenek Avatar answered Oct 01 '22 00:10

Eugenek


I have had great use of the book Practical Perforce. Though you might not be working with Perforce I think that chapter 7 (How Software Evolves) and chapter 8 (Basic Codeline Management) might be very useful. You might be able to skim them on Google Books.

Perforce also has many great articles on the subject. Software Life-Cycle Modeling writes about policies.
Perforce complete technical documentation.

And, no I'm not working for neither with Perforce.

Good luck, Thomas

like image 24
homaxto Avatar answered Oct 01 '22 01:10

homaxto