Forum OpenACS Development: RFC: Move .LRN code into OpenACS Repository

Proposed here with intent to TIP after we agree on the technical details. Most of the details are from Jeff Davis but the errors are all mine.

Abstract

The .LRN source code is maintained in a cvs repository distinct from the openacs repository. This is because of reasons that no longer apply. It imposes unnecessary costs on release management, adds an extra barrier to working on .LRN code, and contributes to the seperation between the two code bases. We should move all of the dotlrn packages into the main openacs cvs repository.

Current Situation

The OpenACS cvs repository is openacs.org:/cvsroot and the .LRN repository is dotlrn.openacs.org:/dotlrn-cvsroot

Execution Plan

  • merge /dotlrn-cvsroot-old/CVSROOT/modules into the normal /cvsroot/modules file.
  • make sure everyone in the dotlrn group is in the cvs group and update the avail file so they have commit.
  • create a script which would update the CVS/* files in an existing dotlrn checkout to reference the new location.
    find . -type f -name 'Root' | xargs perl -pi.bak -e 's/dotlrn-cvsroot/cvsroot/'
    find . -type f -name 'Repository' | xargs perl -pi.bak -e 's/dotlrn.openacs.org/openacs.org/'
    
  • Move the repository
    #rename dotlrn-cvsroot so no one accidentally checks in to the deprecated location
    
    mv /dotlrn-cvsroot /dotlrn-cvsroot-old
    
    tar -czf dotlrn-cvs-bkp.tgz /dotlrn-cvsroot-old
    
    chgrp -R cvs /dotlrn-cvsroot-old
    
    mv /dotlrn-cvsroot-old/{modules} /cvsroot/openacs-4/packages
    # (maybe we should put them in openacs-4/dotlrn/packages though...not
    # sure), need to exclude the CVSROOT directory from mv.
    
Collapse
Posted by Don Baccus on
Yes, now that 2.0 is tagged I'd like to see this happen, as it will facilitate my retrofitting the rewritten portal package to .LRN and will allow us to have one set of portlets that work in both .LRN and OpenACS.  Among other less selfish good reasons, of course!
makes a lot of sense, specially to avoid the overhead of working in two different repositories, in cases like merging branches will be easier to coordinate.
Collapse
Posted by Joel Aufrecht on
Actually, this was already approved as TIP #19, so as soon as .LRN 2.0.3 is released, I will do it.
Collapse
Posted by Joel Aufrecht on
Done.