CCSM Move to Subversion Project Plan

Move to subversion after the CCSM/ESMF Stage-1 project is done.
This will be spring of 2006.
The move to subversion has been bumped up in priority. Initial
planning was underway as of Sept. '05.

• Project Charter
• Brians CAM Subversion Example
• Potential Repository Layout
• Timeline
• Documentation options
• Working with externals
• What about keywords
  Old modules will be left in CVS

  Modules to move:

• ccsm3
• cpl6
• cam1
• datm6
• datm7
• latm6
• pop
• pop2
• docn6
• docn7
• csim4
• dice6
• dice7
• clm2
• dlnd6
• dlnd7
• dead6
• doc
• scripts
• bld
• mct
• mpeu
• mph
• csm_share
• esmf

Modules not sure about

• scyc
• cam1_scyc

Topics raised in recent weeks of reacquainting ourselves with svn

• Should the first version of things in svn match the last version of things in cvs?
• would be nice if initial import to svn did not differ greatly from where we left off in cvs, was guaranteed to compile, and gave bit-for-bit answers
• major restructuring and renaming of files/directories and other cleanup could take place after initial port to svn
• small changes are inevitable as svn will require certain things to be done differently (ie using externals instead of modules etc)
• what do we call the initial tags in svn?
• How do we include required components for a project from other parts of the repository?
• eaton proposed a clever scheme of using svn's copy command to accomplish what modules did in cvs (see link above)
• advantages i've seen in experimenting with svn's externals feature as an alternative (mvr)

  1) externals are set up by simply setting a property on the directory to be populated with linked code 2) documentation of the included files' version is readily available via svn commands for manipulating properties and is not reliant upon users supplying an accurate log message with a copy 3) there are no automatic commits of changes to external code from a sandbox (changes of this code should be done in the actual project for that code) 4) all versions of a projects code will reside in one place of the repository and no unique copies will be located in other source trees

• disadvantages i've seen with using externals (mvr)

  1) as mentioned, commits from a sandbox where there are changes to external code will NOT include a commit of those changes automatically...however the commit of non-external changes occurs without incident, even though they likely require the mods to the external code...the required extra step to specifically commit the external code can be easily overlooked and those changes could be lost if the sandbox is deleted (this may be preventable through the use of a hook script that checked for external mods with any commit - actually no, this did NOT work...hook scripts run on the server side and the information about a commit that is passed there contains no information about mods to external code...this may require a wrapper script for commits that exist on the client side) 2) absolute URL's are required in the definition of externals...these will require modification each time the directory structure of the repository changes

• How should permissions be set up in subversion?
• I found that if you check out an old revision using the -r flag, you can actually commit from that sandbox without any sort of update to the head...scary, but it may not be such a big deal because i wouldn't expect many people to use the -r flag with a revision number if we're using tags...to get an old revision, users should check out the source from the tags directory by name...nothing would prevent users from committing to this code either, unless we make everything under the tags directory read-only, which is what i suggest
• branches, like tags, are just copies, but we'd expect changes to be committed to them...so no write-protection is required of them, although we may want to limit WHO can write to them or who can even see them if private
• these sorts of directory-level permissions are possible through the apache http server