Forum OpenACS Development: Re: Migrating to a branch in the OpenACS repository

Yes maybe. (Let's chat this weekend or something...)

Let's plan out what needs to be done first. You want to be a branch in the normal OpenACS cvs repository and project, have I got that right?

The normal way to run a website like OpenACS would be to create your own cvs project for (which in fact has already been done), and import each release of OpenACS onto a vendor branch in that project. I believe that was also already done for OpenACS, starting with an early 4.5 development snapshot, e.g.:

[andrewp@samoyed]$ pwd
[andrewp@samoyed]$ cvs stat -v readme.txt 
File: readme.txt       	Status: Up-to-date

   Working revision:	Thu Jul 25 19:21:25 2002
   Repository revision:	/cvsroot/,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

   Existing Tags:
	openacs-4-6-beta-2002-10-08	(revision:
	openacs-4-6-beta-2002-08-05	(revision:
	openacs-4-6-devel-2002-07-31	(revision:
	openacs-4-6-devel-2002-07-25	(revision:
	openacs-4-5-devel        	(revision:
	OpenACS                  	(branch: 1.1.1)

The advantage of instead making a branch of the normal OpenACS development tree is that doing so should integrate much more tightly to the stock OpenACS releases, and should make it much easier to merge fixes back into the stock toolkit, and also to aggresively move newly developed toolkit code onto even before a new version of the toolkit is tagged release if (and it's a fairly big if, I think) the maintainers decide they want to do that.

Basically, in this " as branch of toolkit" scanario, becomes another branch of the toolkit to be maintained just like the current 4.6 stable branch, rather than the more typical, more loosely coupled, "cvs import into another project" way of doing things.

I've never done that before, as for most projects (due to the design of CVS) you simply don't even have the option. It sounds like a reasonably good idea, but let's make sure it's the right thing to do. I'd like to see a bit more discussion and planning first, or links to such if that's already happened. Particularly the opinions of other folks like Jeff Davis who have done the most extensive work merging and updating the different OpenACS toolkit branches so far.