Forum OpenACS Q&A: Location of openacs.org cvs tree

Collapse
1: Location of openacs.org cvs tree
Posted by Joel Aufrecht on 01/31/04 07:54 PM
(DaveB, please jump in and correct me as needed) Currently OpenACS.org itself is kept in a CVS repository openacs.org:/cvsroot/openacs.org-dev.  I believe the plan was to maintain openacs.org's source code in a branch of the OpenACS core code.  I'm not sure if the openacs.org-dev branch is part of that plan or not.

DaveB reported "thousands" of merge conflicts when trying to merge the openacs.org code with 5.0, and there was discussion on IRC about starting over from clean 5.0.0  and then putting in only the minimum necessary changes to make the site work as well as it did before.  I think this is the right approach (and it's what I'm doing for my own 4.6 to 5 upgrade), but I'm not convinced where the cvs repository should be.  The argument for it being a branch of openacs.org was a dogfooding one - it makes it more likely for local improvements needed for openacs.org to get back into the codebase.  But it seems to me that we'd get better dogfooding if we really did set up the site the way most production sites do - in their own cvs repositories, with occasional imports from openacs tarballs.

Opinions?

Earlier discussion:
https://openacs.org/forums/message-view?message_id=30020
https://openacs.org/forums/message-view?message_id=121400

Collapse
2: Re: Location of openacs.org cvs tree (response to 1)
Posted by Jeff Davis on 01/31/04 09:26 PM
My view is that generally for features we add they need to be used by a bunch of people before the rough edges get smoothed off. A good example was the upgrade of openacs.org from 3.2.5 to 4.6; just after we did that we got a tremendous amount of feedback about little easy things to fix and we fixed them because we use them all the time. It was the biggest boost to usability in forums and other packages heavily used on openacs.org that we have had to date.

having openacs.org as a testbed for new features provides two things I think are important, one is immediate feedback from the community, and the other is visibility. People see what we are trying out and if something does not work out it fails fast.

Another issue is resources. We really need to make rolling things in to openacs.org and back to the release branch easy. And while I appreciate the sentiment that we should run openacs.org's cvs archive the way we recommend people run a prod site, the downside is merging changes back from openacs.org would be much harder and given the track record so far I doubt it will happen unless it gets easier. The only reason we recommend people run their own cvs archive for their production site is that the better alternative of having a branch in the main openacs.org repository is just not an option for any other site.

Collapse
3: Re: Location of openacs.org cvs tree (response to 1)
Posted by Malte Sussdorff on 02/01/04 11:52 AM
I'm actually more in favour of running OpenACS.org on a stock cvs checkout of the latest release branch and keep the changes in a seperate place. I don't see one reason why OpenACS.org should differ from the toolkit with regards to functionality. If the community wants to use it in a certain way, we better get that code as fast as possible back into the toolkit (and what better way then to use the stock cvs as our repository).

I'm not sure about the nature of the changes that caused so much trouble, but after a CVS update to the latest release, we should be able to re-checkout the changes repository on top of our current installation and be happy with it.

Last but not least, upgrading OpenACS should become considerably less burdensome and be executed on a regular basis. Not wanting to put too much work load on the release manager, but I'd be really happy to see him charge after some people let's say two weeks after the release to upgrade openacs.org to the latest one (and make an upgrade of openacs.org a showstopper for the next release).

Collapse
4: Re: Location of openacs.org cvs tree (response to 3)
Posted by Randy O'Meara on 02/01/04 05:54 PM
but after a CVS update to the latest release, we should be able to re-checkout the changes repository on top of our current installation

What would the cvs checkout/update commands look like?

Collapse
5: Re: Location of openacs.org cvs tree (response to 4)
Posted by Malte Sussdorff on 02/01/04 06:15 PM
What would the cvs checkout/update commands look like?

On the risk of sounding naive:

  • cvs -d /cvsroot update -Pd -r oacs-X-Y
  • cvs -d /cvsroot update -Pd -r openacs-org (different repository)
This assumes, that the changes we are making to openacs.org are only *cosmetic* in nature (mainly templates).
Collapse
6: Re: Location of openacs.org cvs tree (response to 5)
Posted by Randy O'Meara on 02/02/04 06:23 AM
I'm not extremely familiar with cvs but it is my understanding that it's not possible to update from a repository other than the one used for the initial checkout. And this kinda makes sense because there is (as far as I know) specification for one and only one repository (CVSROOT) within the cvs admin files (CVS directory) maintained in each directory.

I was hoping that there was some slick way to mix checkouts from two repositories. It sure would make my life easier.

Thanks,

Randy

Collapse
7: Re: Location of openacs.org cvs tree (response to 1)
Posted by Mark Aufflick on 02/03/04 12:46 AM
I think it depends on how often we want to update openacs.org.

If we, for instance, did a vendor import of openACS-stable regularly, tht wouild be maintainable. But if we wait for major version revisions, then the merges would be almost impossible.

I agree with Malte's suggestion of basing openacs.org on a standard checkout, with a smallish collection of diffs/whatever kept elsewhere.

I also believe that it is essential that openacs.org runs on the latest major version as a minimum. It is, after all, everyone's first experience with OpenACS, and they will be far more motivated to do a download/install if they can see how functional it is.

For instance I think that small things like the spell checking on nearly everything would blow people away and explain better than works about the underlying structure of openacs.

SO I don't think we can avoid the rebuild on 5.0, but we should try and make the functionality be as close to a standard checkout as possible - even if that means changing the look and feel a bit to match our standard. It might even give us a shove along with css/templating the core packages.