Forum OpenACS Development: Best way to create cvs diffs for submitting patches?

I ran into trouble with the patch instructions.

Suppose I maintain a local cvs tree on my own system. Then I have two ways to stay current with the openacs tree. One (detailed in some of the CVS documentation) is to download a tarball, untar it on top of my working directory, and import it with a branch/vendor tag. The other is to check out openacs tree using

cvs -z3 -d :pserver:anonymous@openacs.org:/cvsroot co openacs-4

Question 1) If I want to have my own local tree and also have a checkout tree from openacs.org, must these be two different trees?

Now, I have made changes to an existing package and I want to submit these changes back to Openacs as bug fixes/new features. The only way I see how to do that now, assuming the answer to Question 1 is yes, is this (openacs-4 is the live branch and openacs-dev is my local tree):

cd /web/openacs-4/packages/foo
cvs up -AdP
cp * /web/openacs-dev/packages/foo
cp sql/* /web/openacs-dev/packages/foo/sql
(etc - repeat for all affected directories and hope you don't miss any.  
This process avoids copying the special CVS directories but surely there's a better way)
cvs diff -NRukk /web/openacs-dev/packages/foo > /tmp/my_new_patch.txt

Question 2) Will this work, and is there a better/easier way?

If I were you I would make the changes to the package directly in the checkout of that package. You could do

cd /web/openacs-dev/packages
cvs -d :pserver... checkout -d package_name openacs-4/packages/package_name

to get the package sources into your dev source tree. If you want both local revision control and updates from openacs.org there is a way to do that as well. I think it's described in Andrew Grumet's CVS document (and in other documents) linked here:

http://www.piskorski.com/docs/cvs-conventions.html

Collapse
Posted by Jeff Davis on
You don't need to copy over the files to a current checkout, you could submit a diff from your cvs archive although you need to excercise some care not to pull in any customization that is site specific and not suitable for openacs generally.

In general what we are shooting for is a context diff that is properly formatted to feed to the patch program and contains a change set that is small enough and close enough to the existing HEAD or release branch to be applied automatically.

If you have not made the changes on a current checkout, the next best thing is a diff against the baseline you used for the site (since it will just be the changes you made). If you take the copying route you run the risk of generating a patch which will back out other people changes if other people have made changes to the same file which have been committed to openacs.org.