Index: openacs-4/packages/acs-core-docs/www/xml/engineering-standards/cvs.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/engineering-standards/cvs.xml,v
diff -u -r1.1.2.1 -r1.1.2.2
--- openacs-4/packages/acs-core-docs/www/xml/engineering-standards/cvs.xml 1 Nov 2004 23:40:31 -0000 1.1.2.1
+++ openacs-4/packages/acs-core-docs/www/xml/engineering-standards/cvs.xml 3 Nov 2004 16:37:48 -0000 1.1.2.2
@@ -1,10 +1,10 @@
-
%myvars;
]>
-
+
CVS Guidelines
@@ -13,123 +13,9 @@
By Joel Aufrecht with input from Jeff Davis, Branimir Dolicki, and Jade Rubick.
-
-
- OpenACS CVS Concepts
-
- Modules
-
- All OpenACS code resides within a single CVS module, openacs-4. (The openacs-4 directory contains code for all versions of OpenACS 4 and later, and .LRN 1 and later.) Checking out this module retrieves all openacs code of any type. For convenience, subsets of openacs-4 are repackaged as smaller modules.
-
-
- acs-core contains only critical common
- packages. It does not have any user applications, such as forums,
- bug-tracker, calendar, or ecommerce. These can be added at
- any time.
-
- The complete list of core packages is:
-acs-admin
-acs-api-browser
-acs-authentication
-acs-automated-testing
-acs-bootstrap-installer
-acs-content-repository
-acs-core-docs
-acs-kernel
-acs-lang
-acs-mail
-acs-messaging
-acs-reference
-acs-service-contract
-acs-subsite
-acs-tcl
-acs-templating
-ref-timezones search
-
-
- dotlrn-all contains the packages required, in combination with acs-core, to run the .LRN system.
-
-
-
- project-manager-all contains the packages required, in combination with acs-core, to run the project-manager package.
-
-
-
- Each OpenACS package (i.e., directory in openacs-4/packages/) is also aliased as a module of the same name.
-
-
-
-
-
-
- Tags and Branches
-
-
- Tags and Branches look similar in commands, but behave differently. A tag is a fixed point on a branch. Check out
- a tag to get a specific version of OpenACS. Check out a branch to
- get the most current code for that major-minor version (e.g., 5.0.x
- or 5.1.x). You can only commit to a branch, not a tag, so check out
- a branch if you will be working on the code.
-
-
- openacs-x-y-z-final
- tags mark final releases of OpenACS. This tag is applied to the acs-core files for an OpenACS core release, and to the latest released versions of all other packages at the time of release. Example: openacs-5-0-4-final.
-
-
-
- dotlrn-x-y-z-final
- tags mark final releases of .LRN. These tags apply only to .LRN packages. Example: dotlrn-2-0-1-final
-
-
-
- packagename-x-y-z-final
- tags apply to releases of individual packages. For example, calendar-2-0-0-final is a tag that will retrieve only the files in the calendar 2.0.0 release. It applies only to the
- calendar package. All non-core, non-dotlrn packages should have a
- tag of this style, based on the package name. Many packages have
- not been re-released since the new naming convention was adopted
- and so don't have a tag of this type.
-
-
-
-
- openacs-x-y-compat tags point to the most recent released version of OpenACS X.Y.
- It is similar to openacs-x-y-z-compat, except that it will
- always get the most recent dot-release of Core and the
- most recent compatible, released version of all other
- packages. All of the other tag styles should be static,
- but -compat tags may change over time. If you want version
- 5.0.4 exactly, use the openacs-5-0-4-final tag. If you want the best newest released code in the 5.0.x release series and you want to upgrade within 5.0.x later, use the compat tag.
-
-
- For example, if you check out the entire tree with -r
- openacs-5-0-compat, you might get version 5.0.4 of each OpenACS
- core package, version 2.0.1 of calendar, version 2.0.3 of each .LRN
- package, etc. If you update the checkout two months later, you
- might get version 5.0.5 of all OpenACS core packages and version
- 2.1 of calendar.
-
-
-
- oacs-x-y is a branch, , not a tag. All core packages in the 5.0 release series (5.0.0, 5.0.1, 5.0.2, etc) are also on the oacs-5-0 branch. Similarly, OpenACS core packages for 5.1.0 are on the oacs-5-1 branch.
- These branches are used for two purposes. OpenACS
- Core packages on these branches are being tidied up for
- release. Only bug fixes, not new features, should be
- added to core packages on release branches. For all other
- packages, release branches are the recommended location
- for development. For example, if you are working on
- calendar, which is compatible with openacs 5.0 but not
- 5.1, work on the oacs-5-0 branch.
-
-
- HEAD is a branch used
- for development of core packages.
-
-
-
-
-
+
Using CVS with OpenACS
-
+
Getting Started
All OpenACS code is available anonymously. To get code
@@ -207,9 +93,9 @@
into your ~/.ssh/config file, then you can use -d :ext:cvs-server:/cvsroot instead of -d :ext:openacs.org:/cvsroot. You can then change the definition of cvs-server by changing one file instead of editing hundreds of CVSROOT/Repository files.
-
+
-
+
Checkout for Package Development
If you are actively developing a non-core package, you
should work from the latest core release branch. Currently this
@@ -235,9 +121,9 @@
for a list of available packages and their
current state.
-
+
-
+
Checkout for Core Development
If you are actively developing packages in the OpenACS
Core, work from the HEAD branch. HEAD is used for active
@@ -251,9 +137,9 @@
cvs -d:ext:openacs.org:/cvsroot checkout acs-core
To check out HEAD anonymously:
cvs -d:pserver:anonymous@openacs.org:/cvsroot checkout acs-core
-
+
-
+
Checkout .LRN
.LRN consists of a given version openacs core, plus a set of
@@ -269,17 +155,132 @@
cd dotlrn/packages
cvs -d :pserver:anonymous@openacs.org:/cvsroot checkout -r &releasebranch; dotlrn-all
mv dotlrn/install.xml ..
-
-
-
+
+
Working with CVS
Once you have a checkout you can use some commands to track
what has changed since you checked out your copy. cvs -n update does not change any files, but reports which changes have been updated or locally modified, or are not present in CVS.
To update your files, use cvs update. This will merge changes from the repository with your local files. It has no effect on the openacs.org repository.
-
-
+
+
+
+
+ OpenACS CVS Concepts
+
+ Modules
+
+ All OpenACS code resides within a single CVS module, openacs-4. (The openacs-4 directory contains code for all versions of OpenACS 4 and later, and .LRN 1 and later.) Checking out this module retrieves all openacs code of any type. For convenience, subsets of openacs-4 are repackaged as smaller modules.
+
+
+ acs-core contains only critical common
+ packages. It does not have any user applications, such as forums,
+ bug-tracker, calendar, or ecommerce. These can be added at
+ any time.
+
+ The complete list of core packages is:
+acs-admin
+acs-api-browser
+acs-authentication
+acs-automated-testing
+acs-bootstrap-installer
+acs-content-repository
+acs-core-docs
+acs-kernel
+acs-lang
+acs-mail
+acs-messaging
+acs-reference
+acs-service-contract
+acs-subsite
+acs-tcl
+acs-templating
+ref-timezones search
+
+
+ dotlrn-all contains the packages required, in combination with acs-core, to run the .LRN system.
+
+
+
+ project-manager-all contains the packages required, in combination with acs-core, to run the project-manager package.
+
+
+
+ Each OpenACS package (i.e., directory in openacs-4/packages/) is also aliased as a module of the same name.
+
+
+
+
+
+
+ Tags and Branches
+
+
+ Tags and Branches look similar in commands, but behave differently. A tag is a fixed point on a branch. Check out
+ a tag to get a specific version of OpenACS. Check out a branch to
+ get the most current code for that major-minor version (e.g., 5.0.x
+ or 5.1.x). You can only commit to a branch, not a tag, so check out
+ a branch if you will be working on the code.
+
+
+ openacs-x-y-z-final
+ tags mark final releases of OpenACS. This tag is applied to the acs-core files for an OpenACS core release, and to the latest released versions of all other packages at the time of release. Example: openacs-5-0-4-final.
+
+
+
+ dotlrn-x-y-z-final
+ tags mark final releases of .LRN. These tags apply only to .LRN packages. Example: dotlrn-2-0-1-final
+
+
+
+ packagename-x-y-z-final
+ tags apply to releases of individual packages. For example, calendar-2-0-0-final is a tag that will retrieve only the files in the calendar 2.0.0 release. It applies only to the
+ calendar package. All non-core, non-dotlrn packages should have a
+ tag of this style, based on the package name. Many packages have
+ not been re-released since the new naming convention was adopted
+ and so don't have a tag of this type.
+
+
+
+
+ openacs-x-y-compat tags point to the most recent released version of OpenACS X.Y.
+ It is similar to openacs-x-y-z-compat, except that it will
+ always get the most recent dot-release of Core and the
+ most recent compatible, released version of all other
+ packages. All of the other tag styles should be static,
+ but -compat tags may change over time. If you want version
+ 5.0.4 exactly, use the openacs-5-0-4-final tag. If you want the best newest released code in the 5.0.x release series and you want to upgrade within 5.0.x later, use the compat tag.
+
+
+ For example, if you check out the entire tree with -r
+ openacs-5-0-compat, you might get version 5.0.4 of each OpenACS
+ core package, version 2.0.1 of calendar, version 2.0.3 of each .LRN
+ package, etc. If you update the checkout two months later, you
+ might get version 5.0.5 of all OpenACS core packages and version
+ 2.1 of calendar.
+
+
+
+ oacs-x-y is a branch, , not a tag. All core packages in the 5.0 release series (5.0.0, 5.0.1, 5.0.2, etc) are also on the oacs-5-0 branch. Similarly, OpenACS core packages for 5.1.0 are on the oacs-5-1 branch.
+ These branches are used for two purposes. OpenACS
+ Core packages on these branches are being tidied up for
+ release. Only bug fixes, not new features, should be
+ added to core packages on release branches. For all other
+ packages, release branches are the recommended location
+ for development. For example, if you are working on
+ calendar, which is compatible with openacs 5.0 but not
+ 5.1, work on the oacs-5-0 branch.
+
+
+ HEAD is a branch used
+ for development of core packages.
+
+
+
+
+
+
Contributing code back to OpenACS
There are three main ways to contribute code to OpenACS:
@@ -346,12 +347,15 @@
done
cvs commit: Rebuilding administrative file database
+
+ See
+
-
+
Rules for Committing Code to the OpenACS.org repository
@@ -576,7 +580,7 @@
-
+
Reasons
@@ -619,9 +623,9 @@
needed, and provides a common ancestor between the fork and the
OpenACS code so that patches can be generated.
-
-
-
+
+
+
Informal Guidelines
@@ -739,13 +743,14 @@
-
-
- Additional Resources
-
-
-
- The
+
+
+
+ Additional Resources for CVS
+
+
+
+ The
OpenACS cvs web
and
@@ -772,13 +777,43 @@
-
-
-
+
+
+
+ cvs manual
+
+
+
+
+ adding files/dirs with cvs
+
+
+
+
+ file locking etc. with cvs
+
+
+
+
+ Piskorski's cvs refs
+
+
+
+
+ backup with cvs
+
+
+
+
+ merging 2 file heirarchies with cvs
+
+
+
+
($Id$)
-
+