History: CvsEtiquette

CVS Etiquette

Some advice for 1.8 branch :

• No Format Change it messes up the merges
  After branching no reformatting of code is welcome. Developers have to live with bad indentation or bad line delimiters. As soon as the code runs everywhere, it's o.k.
• No Gremlins they fake diffs and kill mergers
  If developers use new editors/cvs tools they should ensure that the tools don't change whitespace (tabs to spaces and CR/LF to LF or vice versa). Use the content of test/ dir for testing your tool if unsure.
• Only Fixes on BRANCH we need stasis for fix, translation and documentation effort
  New features in HEAD, fixes in BRANCH-X-X. If unsure, ask project admins on irc or in devel list. If unsure, developers should do a cvs diff before cvs commit to ensure that they only commit changes they want to commit.
• Frequent merge from BRANCH to HEAD so fixes come naturally to HEAD
  Merging bugfixes to the HEAD branch should occur at least every week. If blocking bugs are fixed, merging should be done as soon as possible. Merging has to be coordinated on IRC and has to be done by special instructed persons (need some cvs understanding, that's all).
• Only commit on one branch because merges are expected to be frequent
  Do not commit the same changes/fixes in BRANCH and HEAD. Fixes should only go to the BRANCH. They will propagate to HEAD by merging.