fhem-mirror/fhem
rudolfkoenig 42c3c6a80b Preparing the release 4.2
git-svn-id: https://svn.fhem.de/fhem/trunk@119 2b470e98-0d58-463d-a4d8-8e2adae1ed80
2007-12-03 10:49:00 +00:00
..
FHEM Preparing the release 4.2 2007-12-03 10:49:00 +00:00
contrib M232 merge, some new snapshots 2007-11-27 09:14:25 +00:00
docs Preparing the release 4.2 2007-12-03 10:49:00 +00:00
examples FHT softbuffer rewrite, module reorganization, support for M232 2007-11-26 08:27:04 +00:00
test fhemweb.pl tuning 2007-10-03 16:35:37 +00:00
webfrontend Size/axis chenges, new piri logs 2007-12-03 10:34:34 +00:00
CHANGED Small fix to avoid unintialized messages when no IODevice is set. 2007-12-03 09:56:06 +00:00
HISTORY FHT softbuffer rewrite, module reorganization, support for M232 2007-11-26 08:27:04 +00:00
Makefile Preparing the release 4.2 2007-12-03 10:49:00 +00:00
README.CVS cvsrc description 2007-02-17 15:32:59 +00:00
fhem.pl softbuffer fixes 2007-11-27 15:17:47 +00:00

README.CVS

The source of this project is hosted on Berlios, if you wish you can get
the latest version with the following commands:
  cvs -d:pserver:anonymous@cvs.fhem.berlios.de:/cvsroot/fhem login
  cvs -z3 -d:pserver:anonymous@cvs.fhem.berlios.de:/cvsroot/fhem co fhem

If you wish to contribute to the project, then
- create a berlios account 
- send an email to the project manager to add you as developer to the project
  (right know this is r dot koenig at koeniglich dot de)
- check out the source with
   % cvs -z3 -d<berlios-uid>@cvs.berlios.de:/cvsroot/fhem co fhem
- if it is already checked out, it makes sense to do an update before
  implementing your changes:
   % cvs update
- make your changes
- test if it is working (Really !!!)
- make an entry in the CHANGED file, giving your changes a "title".
- describe your changes in the file HISTORY, and dont forget to mention your
  name and the date of change
- it makes sense to do a "cvs diff" before checking in the stuff with
    cvs commit
- if you do complex/nontrivial changes affecting more than one file, then 
  please tag the whole software before and after the change with:
  - before: % cvs tag <berlios-uid>_<date_as_YYYYMMDD>_0
  - after:  % cvs tag <berlios-uid>_<date_as_YYYYMMDD>_1
  You can increase the counter for bugfixing. Dont forget to mention the 
  tagname in the HISTORY file. Tagging helps to remove more complex changes or
  to merge them in other releases/branches.


Some useful CVS commands/flags for the beginner:


# Get the newest stuff from the server and merge it into your changes.
# Watch out for lines beginning with C (collisions), edit them  immediately
# after check out, and look for ==== 
# Without -d new directories won't be checked out
cvs update -d . 

# Before checking in, make sure you changed only what you intended:
cvs diff filename

# Add new file. "-kb" adds binary files. Forgetting -kb will cause
# problems if somebody is checking out on a different OS (windows)
# Note: it is complicated to rename files in CVS, so think twice about
# filenames before adding them. e.g. do not use version names in them.
cvs add [-kb] filename

# Look at the change history
cvs log <filename>

# Commit changes. Set the EDITOR environment variable to use your editor.
cvs commit .

# Check which files were changed. Type ^C when it asks you to really release it.
# (is there a more elegant way?)
cvs release .

# We recommend to set some options in our ~/.cvsrc file:
cvs -q
update -d
# The 'cvs -q' option will suppress some output e.g. during update
# only the updated and unknown files etc. are displayed (not every
# folder etc.).
# The 'update -d' will automatically create folders as required.