Page MenuHomeHEPForge
Files F8310206

---README_1st_SVN---
No OneTemporary
Actions

---README_1st_SVN---
View Options

Groundrules for Working With the WHIZARD SVN Repository
=======================================================
RULE #0:
Make yourself familiar with the CONCEPTS and PHILOSOPHY of
SVN
http://svnbook.red-bean.com/ [required reading]
GNU Autotools
http://www.gnu.org/software/automake/manual/ [required reading]
http://www.gnu.org/software/autoconf/manual/
http://www.gnu.org/software/libtool/manual/
Layout of the Repository
------------------------
trunk/
This is the current development version and must ALWAYS compile
(i.e. "make all" and "make install" must go through). Under
extraordinary circumstances, other make targets can fail for a
short period of time. Please use branches for medium and large
scale developments - in particular of the build system.
(See also "Commiting To the Trunk" below)
branches/
Branching is a fundamental part of version control. If you're
going to allow Subversion to manage your data, this is a
feature you'll eventually come to depend on.
[http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge]
While it is convenient to make SMALL changes that affect only
one ore two files in the trunk, you are requested to ALWAYS
perform major surgery in a branch. After you're done, you can
easily merge your changes to the trunk and subsequently commit a
werking version. The SVN Book [http://svnbook.red-bean.com/]
has all the details.
branches/jr_reuter/
branches/kilian/
branches/ohl/
branches/speckner/
Private sandboxes of developers: no rules apply here.
tags/
These are snapshots of the code, correspondig to tarballs and to
checkpoints before and after major surgery. They should ONLY be
created with "svn cp" and NEVER be commited to (that's what
branches are for).
Commiting To the Trunk
----------------------
RULE #1:
You may UNDER NO CIRCUMSTANCES commit a version to the trunk in
which "make all" or "make install" fail with an accepted compiler
(at the moment: gfortran 4.5 or NAG).
Repeated violations of this rule will lead to the loss of commit
priviledges.
Rationale:
It is crucial that other developers can "svn update" all the time
in order to reduce the risk of conflicts without the danger of
losing the ability to test their contributions.
RULE #2:
There can be circumstances in which it is necessary to commit
versions to the trunk in which one or more of "make check", "make
installcheck", "make dist" or "make distcheck" fail. This should
be avoided, though.
Rationale:
Debugging failures of "make distcheck" can take a long time and it
can be more important to communicate your changes to the other
developers.
Renaming Files
--------------
RULE #3:
If you want to rename a file, NEVER use "cp old-name new-name; svn
rm old-name; svn add new-name". Use "svn mv old-name new-name"
instead.
Rationale:
The first variant might look the same, but destroys
valuable metainformation, that is required by "svn merge".
See also:
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html
Special commits
--------------
RULE #4:
Whenever you perform a "milennium" commit (a plain thousand like
r1000 or r2000), re-grant the write permissions to the WHIZARD
group on the HepForge svn server by the following commands
(e.g. for r50000):
chmod g+w /hepforge/svn/whizard/db/revs/50
chmod g+w /hepforge/svn/whizard/db/revprops/50
$Id: ---README_1st_SVN--- 2010 2010-03-06 11:44:11Z jr_reuter $
Local Variables:
mode:indented-text
End:

File Metadata

Mime Type
text/plain
Expires
Sat, Dec 21, 5:42 PM (12 h, 39 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
4007868
Default Alt Text
---README_1st_SVN--- (3 KB)

Event Timeline