:ext:foobar\@cvs.openacs.org:/cvsroot. The
+"foobar" it will try to check out and commit as if you
+had specified :ext:foobar\@cvs.openacs.org:/cvsroot. The
advantage of not specifying a user in the checkout command is that
other users can work in the directory using their own accounts.OpenACS.org supports non-anonymous cvs access only over ssh, so
you must have CVS_RSH=ssh in
@@ -54,7 +54,7 @@
Administrator Note: These are the steps to grant CVS commit rights to a user:
Create the user's account. On cvs.openacs.org:
sudo bash
+Create the user's account. On cvs.openacs.org:
sudo bash
/usr/sbin/useradd -c "Real Name" -G cvs -p passwdusername
/usr/sbin/usermod -G cvs,usernameusername
@@ -193,7 +193,8 @@
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
@@ -346,15 +347,17 @@
script. E.g., the last planned upgrade script for a package
previously in dev 1 would be upgrade-2.0.0d1-2.0.0b1.sql, not
upgrade-2.0.0d1-2.0.0.sql. Note that using rc1 instead of b1 would
-be nice, because that's the convention with release codes in cvs,
-but the package manager doesn't support rc tags.
Database upgrade scripts should never go to the release version, e.g., should always have a letter suffix such as d1 or b1.
CVS commit messages should be intelligible in the context of Changelogs. They should not refer to the files or versions.
CVS commit messages and code comments should refer to bug, tip, -or patch number if appropriate, in the format "resolves bug 11", -"resolves bugs 11, resolves bug 22". "implements tip 42", -"implements tip 42, implements tip 50", "applies patch 456 by User -Name", "applies patch 456 by User Name, applies patch 523 by +or patch number if appropriate, in the format "resolves bug +11", "resolves bugs 11, resolves bug 22". +"implements tip 42", "implements tip 42, implements +tip 50", "applies patch 456 by User Name", +"applies patch 456 by User Name, applies patch 523 by ...".
Tags
When a package is released in final form, the developer shall -tag it "packagename-x-y-z-final" and "openacs-x-y-compat". x-y -should correspond to the current branch. If the package is -compatible with several different core versions, several compat -tags should be applied.
Reason 1: The packagename tag is a +tag it "packagename-x-y-z-final" and +"openacs-x-y-compat". x-y should correspond to the +current branch. If the package is compatible with several different +core versions, several compat tags should be applied.
Reason 1: The packagename tag is a permanent, static tag that allows for future comparison. The compat tag is a floating tag which is used by the repository generator to determine the most recent released version of each package for each @@ -404,10 +407,11 @@ the fork and the OpenACS code so that patches can be generated.
For example, adding a new API function wouldn't require a TIP. -Changing an existing API function by adding an optional new flag -which defaults to no-effect wouldn't require a TIP. Added a new -mandatory flag to an existing function would require a TIP.
+For example, adding a new API function wouldn't require a +TIP. Changing an existing API function by adding an optional new +flag which defaults to no-effect wouldn't require a TIP. Added +a new mandatory flag to an existing function would require a +TIP.
Never rush to commit something. Before committing double check with cvs diff what exactly you are committing.
Always accompany a commit with a brief but informative comment. If your commit is related to bug number N and/or patch number P, -indicate this in the commit comment by including "bug N" and/or -"patch P". This allows us to link bugs and patches in the Bug -Tracker with changes to the source code. For example suppose you -are committing a patch that closes a missing HTML tag, then an -appropriate comment could be "Fixing bug 321 by applying patch 134. -Added missing h3 HTML close tag".
Commit one cohesive bug fix or feature change at a time. Don't -put a bunch of unrelated changes into one commit.
Before you throw out or change a piece of code that you don't -fully understand, use cvs annotate and cvs log on the file to see -who wrote the code and why. Consider contacting the author.
Test your change before committing. Use the OpenACS package +indicate this in the commit comment by including "bug N" +and/or "patch P". This allows us to link bugs and patches +in the Bug Tracker with changes to the source code. For example +suppose you are committing a patch that closes a missing HTML tag, +then an appropriate comment could be "Fixing bug 321 by +applying patch 134. Added missing h3 HTML close tag".
Commit one cohesive bug fix or feature change at a time. +Don't put a bunch of unrelated changes into one commit.
Before you throw out or change a piece of code that you +don't fully understand, use cvs annotate and cvs log on the +file to see who wrote the code and why. Consider contacting the +author.
Test your change before committing. Use the OpenACS package acs-automated-testing to test Tcl procedures and the tool Tclwebtest to test pages
Keep code simple, adhere to conventions, and use comments liberally.
In general, treat the code with respect, at the same time, never stop questioning what you see. The code can always be improved, @@ -448,12 +453,12 @@
The OpenACS cvs web and Jeff's cvs browser -are useful tools in understanding what is happening with the -code.
There is a mailing list of cvs changes at willfork.com +
The OpenACS cvs web and Jeff's cvs +browser are useful tools in understanding what is happening +with the code.
There is a mailing list of cvs changes at willfork.com
There is an RSS feed of cvs changes at RSS feed -